[Crash-utility] [PATCH] Fixed the segment fault when ikconfig passed nonstandard values
刘云
liuyun01 at tj.kylinos.cn
Mon Jan 4 05:52:34 UTC 2021
在 2021/1/4 下午1:00, d.hatayama at fujitsu.com 写道:
>>> Some strange reasons may cause kcore to collect some strange
>>> entries of ikconfig, such as CONFIG_SECU+[some hex data] causes
>> Could you tell me the example of such CONFIG_SEC+[some hex data] that
>> causes the val to have NULL. I tried to reproduce but failed.
It's hard to say about that, because It's just appeared in the virtual
machine, when I debug
with vmcore (Not a dump.xxx file in my memory).
Ubuntu-kernel/debian/rules.d/2-binary-arch.mk has that:
$(stampdir)/stamp-prepare-tree-%: $(archconfdir)/kylinos_%_defconfig
debian/scripts/fix-filenames
@echo Debug: $@
install -d $(builddir)/build-$*
touch $(builddir)/build-$*/ubuntu-build
[ "$(do_full_source)" != 'true' ] && true || \
rsync -a --exclude debian --exclude debian.master
--exclude $(DEBIAN) * $(builddir)/build-$*
cat $(wordlist 1,3,$^) | sed -e
's/.*CONFIG_VERSION_SIGNATURE.*/CONFIG_VERSION_SIGNATURE="KYLINOS
$(release)-$(revision)-$* $(raw_kernelversion)"/' >
$(builddir)/build-$*/.config
find $(builddir)/build-$* -name "*.ko" | xargs rm -f
$(build_cd) $(kmake) $(build_O) -j1 olddefconfig syncconfig
prepare scripts
touch $@
Every time, '.config' has object file 'fix-filenames' hex data with
config, maybe that is an reason, but
I'm not sure. Maybe It's just any other strange reason cause
/proc/vmcore has CONFIG_SECU+[hex data].
> I guess you mean CONFIG_SECU+[some hex data] to be **strings that don't
> contain the delimitor string '='** and then strtok_r() interprets
> it as consisting of a single token, hence val resulting in having NULL.
> If so, I think it's better to write so.
Yes, It is.
>
> OTOH, due to the cause of this issue, is there also possibility
> that the broken line contains two or more '=' and broken name
> and values are appended in the ikconfig list? It has to be less
> important than here because it doesn't result in segfault, but
> it might be necessary to deal with it too depending on its actual impact.
>
Agree with you.
---
Thanks, BR.
Jackie Liu.
More information about the Crash-utility
mailing list