Re: [Crash-utility] [PATCH v2] Fixed the segment fault when ikconfig passed nonstandard values
by lijiang
在 2021年01月05日 20:12, crash-utility-request(a)redhat.com 写道:
> Date: Tue, 5 Jan 2021 09:45:11 +0800
> From: liuyun01(a)tj.kylinos.cn
> To: crash-utility(a)redhat.com
> Cc: d.hatayama(a)fujitsu.com
> Subject: [Crash-utility] [PATCH v2] Fixed the segment fault when
> ikconfig passed nonstandard values
> Message-ID: <20210105014511.1709-1-liuyun01(a)tj.kylinos.cn>
> Content-Type: text/plain; charset=UTF-8
>
> From: Jackie Liu <liuyun01(a)kylinos.cn>
>
> Some strange reasons may cause kcore to collect some strange
> entries of ikconfig, such as CONFIG_SECU+[some hex data] causes
> the 'val' to be NULL, and then crashes when strdup.
>
> 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.
>
Thank you for the fix.
Acked-by: Lianbo Jiang <lijiang(a)redhat.com>
> [d.hatayama(a)fujitsu.com: rewrite comment]
> Suggested-by: HAGIO KAZUHITO(?? ??) <k-hagio-ab(a)nec.com>
> Signed-off-by: Jackie Liu <liuyun01(a)kylinos.cn>
> ---
> kernel.c | 14 +++++++++++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/kernel.c b/kernel.c
> index 9871637..c8182a6 100644
> --- a/kernel.c
> +++ b/kernel.c
> @@ -10236,7 +10236,7 @@ static struct ikconfig_list {
> char *val;
> } *ikconfig_all;
>
> -static void add_ikconfig_entry(char *line, struct ikconfig_list *ent)
> +static int add_ikconfig_entry(char *line, struct ikconfig_list *ent)
> {
> char *tokptr, *name, *val;
>
> @@ -10244,8 +10244,16 @@ static void add_ikconfig_entry(char *line, struct ikconfig_list *ent)
> sscanf(name, "CONFIG_%s", name);
> val = strtok_r(NULL, "", &tokptr);
>
> + if (!val) {
> + if (CRASHDEBUG(2))
> + error(WARNING, "invalid ikconfig entry: %s\n", line);
> + return FALSE;
> + }
> +
> ent->name = strdup(name);
> ent->val = strdup(val);
> +
> + return TRUE;
> }
>
> static int setup_ikconfig(char *config)
> @@ -10265,8 +10273,8 @@ static int setup_ikconfig(char *config)
> ent++;
>
> if (STRNEQ(ent, "CONFIG_")) {
> - add_ikconfig_entry(ent,
> - &ikconfig_all[kt->ikconfig_ents++]);
> + if (add_ikconfig_entry(ent, &ikconfig_all[kt->ikconfig_ents]))
> + kt->ikconfig_ents++;
> if (kt->ikconfig_ents == IKCONFIG_MAX) {
> error(WARNING, "ikconfig overflow.\n");
> return 1;
> -- 2.17.1
3 years, 10 months
Re: [Crash-utility] [PATCH v3 1/1] Support cross-compilation
by lijiang
在 2021年01月12日 16:24, crash-utility-request(a)redhat.com 写道:
> Date: Mon, 11 Jan 2021 18:47:41 +0100
> From: Alexander Egorenkov <egorenar(a)linux.ibm.com>
> To: lijiang <lijiang(a)redhat.com>, crash-utility(a)redhat.com,
> egorenar-dev(a)posteo.net
> Subject: Re: [Crash-utility] [PATCH v3 1/1] Support cross-compilation
> Message-ID: <87ft37tlfm.fsf(a)oc8242746057.ibm.com>
> Content-Type: text/plain
>
>
>> After applied this patch, the cross build failed in Fedora as below:
>>
>> [root@hpe-apollo-cn99xx-15-vm-21 crash]# make CROSS_COMPILE=s390x-linux-
>> ...
>> rm -f ./libiberty.a pic/./libiberty.a
>> s390x-linux-ar rc ./libiberty.a \
>> ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./sha1.o ./alloca.o ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./crc32.o ./dwarfnames.o ./dyn-string.o ./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o ./fnmatch.o ./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative-prefix.o ./make-temp-file.o ./mkstemps.o ./objalloc.o ./obstack.o ./partition.o ./pexecute.o ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./safe-ctype.o ./simple-object.o ./simple-object-coff.o ./simple-object-elf.o ./simple-object-mach-o.o ./simple-object-xcoff.o ./sort.o ./spaces.o ./splay-tree.o ./stack-limit.o ./strerror.o ./strsignal.o ./timeval-utils.o ./unlink-if-ordinary.o ./xatexit.o ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./xstrndup.o ./setproctitle.o
>> make[4]: s390x-linux-ar: Command not found
>> make[4]: *** [Makefile:247: libiberty.a] Error 127
>> make[3]: *** [Makefile:6996: all-libiberty] Error 2
>> make[2]: *** [Makefile:835: all] Error 2
>>
>> crash build failed
>>
>> make[1]: *** [Makefile:281: gdb_merge] Error 1
>> make: *** [Makefile:272: all] Error 2
>> [root@hpe-apollo-cn99xx-15-vm-21 crash]#
>>
>>
>> Can you help to check this patch again and do some coverage testing?
>>
>> Thanks.
>> Lianbo
>>
> Hi Lianbo,
>
> sorry for the late response, just came back from vacation.
>
No worry.
> For testing i used buildroot because you not only need the whole
> cross-compilation toolchain with linker, ar etc but also some libraries
> compiled for the chosen target e.g. ncurses and zlib. buildroot
> provides it all already. And since November buildroot supports 390x arch.
>
I have installed the whole cross-compilation toolchain in Fedora.
Or I missed something else? Could you please also verify this patch in Fedora?
> I also tried with Debian x86 which provides s390x cross-toolchain but it stopped with termcap library not
> found :( It is even wore for Fedora 32. I used buildroot because i do not want to build the whole cross
> toolchain and libraries.
> Some cross-toolchains are available in Fedora, for example:
On x86_64 machine:
[root@intel-s3ea2-09 crash]# rpm -qa|grep s390
binutils-s390x-linux-gnu-2.35.1-1.fc33.x86_64
gcc-s390x-linux-gnu-10.2.1-3.fc33.x86_64
And on other arches such as s390, ppc64le, Fedora has a similar cross-compilation
> I can provide the buildroot package for crash-utility if necessary.
>
The buildroot is one of the scenarios for the cross-compilation. Maybe we could think more
about this. What's your opinion?
Thanks.
Lianbo
> Regards
> Alex
3 years, 10 months
Re: [Crash-utility] [PATCH] extensions/eppic.mk: move ping check to recipe script
by lijiang
Hi, Kazu
Sorry for the late reply.
在 2020年12月24日 01:00, crash-utility-request(a)redhat.com 写道:
> Date: Wed, 23 Dec 2020 07:59:20 +0000
> From: HAGIO KAZUHITO(?????) <k-hagio-ab(a)nec.com>
> To: lijiang <lijiang(a)redhat.com>, "crash-utility(a)redhat.com"
> <crash-utility(a)redhat.com>
> Subject: Re: [Crash-utility] [PATCH] extensions/eppic.mk: Remove ping
> checkto github.com
> Message-ID:
> <OSBPR01MB1991452F2013C712F2BAACE7DDDE0(a)OSBPR01MB1991.jpnprd01.prod.outlook.com>
>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Lianbo,
>
> -----Original Message-----
>>>>> -GITHUB := $(shell ping -c 1 github.com | grep "1 received")
>>>> BTW: Is it possible to fix this issue with the option -W? For example:
>>>>
>>>> GITHUB := $(shell ping -c 1 -W 2 github.com | grep "1 received")
>>>> ^^^^
>>> No, this doesn't solve the former issue in an environment where ping
>>> doesn't work but "git clone" does work. I have such an environment..
>>>
>> Interesting. Seems that ping doesn't work because of the network policy
>> or other reason?
> Probably it's the network policy.
>
>> For my side, the -W option will provide a timeout.
>>
>>> In the first place, what is the ping check needed for? I'm not sure
>>> why it is there. If it's for avoiding long timeout of "git clone",
>>> it would not be solved by the ping check everywhere, i.e. in a place
>>> where ping works but git clone doesn't work. In this case, something
>>> like "timeout 20 git clone ..." might be better.
>>>
>> This still depends on the network speed.
>>
>> Anyway, this change looks good. Acked-by: Lianbo Jiang <lijiang(a)redhat.com>
> Thanks, but sorry, I've changed my mind..
>
> For safety, I would like to keep the ping check, and I will give up
> the automated "git clone" in the specific environment. I found that
> I can build it by manual "git clone" and "make extensions".
>
> Could you check the following patch again?
>
Sure. The following change also looks good. Thanks.
Ack-by: Lianbo Jiang <lijiang(a)redhat.com>
>
>>From dd4bf22a49b36141afb0c0912171170b8ab2ae01 Mon Sep 17 00:00:00 2001
> From: Kazuhito Hagio <k-hagio-ab(a)nec.com>
> Date: Wed, 23 Dec 2020 16:38:41 +0900
> Subject: [PATCH] extensions/eppic.mk: move ping check to recipe script
>
> Without this patch, in an environment where ping to github.com does
> not work, "make clean" at the top-level crash directory always takes
> about 10 seconds unnecessarily.
>
> $ time make clean
> ...
> real 0m10.398s
>
> Signed-off-by: Kazuhito Hagio <k-hagio-ab(a)nec.com>
> ---
> extensions/eppic.mk | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/extensions/eppic.mk b/extensions/eppic.mk
> index c79170a596b7..bda69da6706f 100644
> --- a/extensions/eppic.mk
> +++ b/extensions/eppic.mk
> @@ -24,7 +24,6 @@ ifeq ($(TARGET), X86)
> endif
>
> APPFILE=eppic/applications/crash/eppic.c
> -GITHUB := $(shell ping -c 1 github.com | grep "1 received")
> GIT := $(shell which git 2> /dev/null)
>
> all:
> @@ -38,7 +37,7 @@ all:
> if [ -n "$(EPPIC_GIT_URL)" ]; then \
> git clone "$(EPPIC_GIT_URL)" eppic; \
> else \
> - if [ -n "$(GITHUB)" ] ; then \
> + if ping -c 1 -W 5 github.com >/dev/null ; then \
> git clone https://github.com/lucchouina/eppic.git eppic; \
> fi; \
> fi; \
> -- 2.18.4
3 years, 10 months
Re: [Crash-utility] [PATCH v3 1/1] Support cross-compilation
by lijiang
Hi, Alexander
Thanks for the patch.
在 2020年11月08日 01:00, crash-utility-request(a)redhat.com 写道:
> Date: Fri, 6 Nov 2020 19:48:07 +0100
> From: Alexander Egorenkov <egorenar-dev(a)posteo.net>
> To: crash-utility(a)redhat.com
> Subject: [Crash-utility] [PATCH v3 1/1] Support cross-compilation
> Message-ID: <20201106184807.29574-1-egorenar-dev(a)posteo.net>
> Content-Type: text/plain; charset="US-ASCII"
>
> In order to support cross-compilation of crash-utilty,
> the configure tool compiled from configure.c must be built
> for the host architecture where the cross-compilation will run
> instead of the target architecture where the crash-utility shall run.
> Therefore, we need to support two C compilers in Maklefile,
> one for the host and one for the target. The old CC makefile variable
> shall represent the compiler for the target architecture and
> the new HOSTCC makefile variable shall represent the host compiler.
> Both variables differ only when a cross-compilation is performed.
> Furthermore, there must be a way to override the target architecture
> which is deduced from the preprocessor macros defined by the compiler
> used for the compilation of configure.c, because otherwise the configure
> tool will deduce host's architecture instead of the desired target.
> With the new preprocessor define CONF_DEFAULT_TARGET, it is possible to
> set the desired target architecture for the compiled crash-utility.
> When cross-compiling, set the makefile variable CROSS_COMPILE
> to the prefix of the cross-compiler and the default target
> architecture will be deduced from it, e.g. like this:
>
> make CROSS_COMPILE=s390x-linux-
>
After applied this patch, the cross build failed in Fedora as below:
[root@hpe-apollo-cn99xx-15-vm-21 crash]# make CROSS_COMPILE=s390x-linux-
...
rm -f ./libiberty.a pic/./libiberty.a
s390x-linux-ar rc ./libiberty.a \
./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./sha1.o ./alloca.o ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./crc32.o ./dwarfnames.o ./dyn-string.o ./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o ./fnmatch.o ./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative-prefix.o ./make-temp-file.o ./mkstemps.o ./objalloc.o ./obstack.o ./partition.o ./pexecute.o ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./safe-ctype.o ./simple-object.o ./simple-object-coff.o ./simple-object-elf.o ./simple-object-mach-o.o ./simple-object-xcoff.o ./sort.o ./spaces.o ./splay-tree.o ./stack-limit.o ./strerror.o ./strsignal.o ./timeval-utils.o ./unlink-if-ordinary.o ./xatexit.o ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./xstrndup.o ./setproctitle.o
make[4]: s390x-linux-ar: Command not found
make[4]: *** [Makefile:247: libiberty.a] Error 127
make[3]: *** [Makefile:6996: all-libiberty] Error 2
make[2]: *** [Makefile:835: all] Error 2
crash build failed
make[1]: *** [Makefile:281: gdb_merge] Error 1
make: *** [Makefile:272: all] Error 2
[root@hpe-apollo-cn99xx-15-vm-21 crash]#
Can you help to check this patch again and do some coverage testing?
Thanks.
Lianbo
> and the default target architecture shall be S390X.
>
> Signed-off-by: Alexander Egorenkov <egorenar-dev(a)posteo.net>
> ---
>
> v2 -> v3:
> * Use CROSS_COMPILE makefile variable to pass cross-compiler prefix
>
> v1 -> v2:
> * Improved commit message
> * Added a note how to cross-compile crash-utilty to README
> * Moved CONF_CC makefile variable to correct place location
>
>
> Makefile | 53 +++++++++++++++++++++++++++++++++++++++++++++++++----
> README | 5 +++++
> configure.c | 39 +++------------------------------------
> 3 files changed, 57 insertions(+), 40 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index d185719..7185dcd 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -20,15 +20,60 @@
> PROGRAM=crash
>
> #
> -# Supported targets: X86 ALPHA PPC IA64 PPC64 SPARC64
> +# Supported targets: X86 X86_64 IA64 ALPHA PPC PPC64 ARM ARM64 SPARC64 MIPS S390 S390X
> # TARGET and GDB_CONF_FLAGS will be configured automatically by configure
> #
> TARGET=
> GDB_CONF_FLAGS=
>
> -ARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ -e s/arm.*/arm/ -e s/sa110/arm/)
> +ifneq ($(CROSS_COMPILE),)
> +ARCH := $(shell echo $(CROSS_COMPILE) | sed 's:^.*/::g' | cut -d- -f1)
> +else
> +ARCH := $(shell uname -m)
> +endif
> +ARCH := $(shell echo $(ARCH) | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ -e s/arm.*/arm/ -e s/sa110/arm/)
> +
> +CC = $(CROSS_COMPILE)gcc
> +HOSTCC = gcc
> +
> ifeq (${ARCH}, ppc64)
> -CONF_FLAGS = -m64
> +CONF_FLAGS += -m64
> +endif
> +
> +ifeq (${ARCH}, i386)
> +CONF_DEFAULT_TARGET := X86
> +else ifeq (${ARCH}, x86_64)
> +CONF_DEFAULT_TARGET := X86_64
> +else ifeq (${ARCH}, ia64)
> +CONF_DEFAULT_TARGET := IA64
> +else ifeq (${ARCH}, alpha)
> +CONF_DEFAULT_TARGET := ALPHA
> +else ifeq (${ARCH}, ppc)
> +CONF_DEFAULT_TARGET := PPC
> +else ifeq (${ARCH}, ppc64)
> +CONF_DEFAULT_TARGET := PPC64
> +else ifeq (${ARCH}, ppc64le)
> +CONF_DEFAULT_TARGET := PPC64
> +else ifeq (${ARCH}, arm)
> +CONF_DEFAULT_TARGET := ARM
> +else ifeq (${ARCH}, aarch64)
> +CONF_DEFAULT_TARGET := ARM64
> +else ifeq (${ARCH}, mips)
> +CONF_DEFAULT_TARGET := MIPS
> +else ifeq (${ARCH}, sparc64)
> +CONF_DEFAULT_TARGET := SPARC64
> +else ifeq (${ARCH}, s390)
> +CONF_DEFAULT_TARGET := S390
> +else ifeq (${ARCH}, s390x)
> +CONF_DEFAULT_TARGET := S390X
> +else
> +$(error unsupported architecture ${ARCH})
> +endif
> +
> +CONF_FLAGS += -DCONF_DEFAULT_TARGET=${CONF_DEFAULT_TARGET}
> +
> +ifneq ($(CROSS_COMPILE),)
> +CONF_FLAGS += -DGDB_TARGET_DEFAULT="\"GDB_CONF_FLAGS=--host=$(shell echo $(CROSS_COMPILE) | sed -e 's:^.*/::g' -e 's/-$$//')\""
> endif
>
> #
> @@ -288,7 +333,7 @@ force:
>
> make_configure: force
> @rm -f configure
> - @${CC} ${CONF_FLAGS} -o configure configure.c ${WARNING_ERROR} ${WARNING_OPTIONS}
> + @${HOSTCC} ${CONF_FLAGS} -o configure configure.c ${WARNING_ERROR} ${WARNING_OPTIONS}
>
> clean: make_configure
> @./configure ${CONF_TARGET_FLAG} -q -b
> diff --git a/README b/README
> index bfbaef6..f5bd476 100644
> --- a/README
> +++ b/README
> @@ -100,6 +100,11 @@
> o On an x86_64 host, an x86_64 binary that can be used to analyze
> ppc64le dumpfiles may be built by typing "make target=PPC64".
>
> + To cross-compile the crash utility, set the makefile variable CROSS_COMPILE to
> + the prefix of the cross-compiler, e.g. like this:
> +
> + $ make CROSS_COMPILE=s390x-linux-
> +
> Traditionally when vmcores are compressed via the makedumpfile(8) facility
> the libz compression library is used, and by default the crash utility
> only supports libz. Recently makedumpfile has been enhanced to optionally
> diff --git a/configure.c b/configure.c
> index 7f6d19e..970a547 100644
> --- a/configure.c
> +++ b/configure.c
> @@ -154,7 +154,9 @@ void add_extra_lib(char *);
> #define TARGET_CFLAGS_MIPS_ON_X86_64 "TARGET_CFLAGS=-m32 -D_FILE_OFFSET_BITS=64"
> #define TARGET_CFLAGS_SPARC64 "TARGET_CFLAGS="
>
> +#ifndef GDB_TARGET_DEFAULT
> #define GDB_TARGET_DEFAULT "GDB_CONF_FLAGS="
> +#endif
> #define GDB_TARGET_ARM_ON_X86 "GDB_CONF_FLAGS=--target=arm-elf-linux"
> #define GDB_TARGET_ARM_ON_X86_64 "GDB_CONF_FLAGS=--target=arm-elf-linux CFLAGS=-m32"
> #define GDB_TARGET_X86_ON_X86_64 "GDB_CONF_FLAGS=--target=i686-pc-linux-gnu CFLAGS=-m32"
> @@ -349,42 +351,7 @@ get_current_configuration(struct supported_gdb_version *sp)
> static char buf[512];
> char *p;
>
> -#ifdef __alpha__
> - target_data.target = ALPHA;
> -#endif
> -#ifdef __i386__
> - target_data.target = X86;
> -#endif
> -#ifdef __powerpc__
> - target_data.target = PPC;
> -#endif
> -#ifdef __ia64__
> - target_data.target = IA64;
> -#endif
> -#ifdef __s390__
> - target_data.target = S390;
> -#endif
> -#ifdef __s390x__
> - target_data.target = S390X;
> -#endif
> -#ifdef __powerpc64__
> - target_data.target = PPC64;
> -#endif
> -#ifdef __x86_64__
> - target_data.target = X86_64;
> -#endif
> -#ifdef __arm__
> - target_data.target = ARM;
> -#endif
> -#ifdef __aarch64__
> - target_data.target = ARM64;
> -#endif
> -#ifdef __mips__
> - target_data.target = MIPS;
> -#endif
> -#ifdef __sparc_v9__
> - target_data.target = SPARC64;
> -#endif
> + target_data.target = CONF_DEFAULT_TARGET;
>
> set_initial_target(sp);
>
> -- 2.29.2
3 years, 10 months
[PATCH v2] Fixed the segment fault when ikconfig passed nonstandard values
by liuyun01＠tj.kylinos.cn
From: Jackie Liu <liuyun01(a)kylinos.cn>
Some strange reasons may cause kcore to collect some strange
entries of ikconfig, such as CONFIG_SECU+[some hex data] causes
the 'val' to be NULL, and then crashes when strdup.
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.
[d.hatayama(a)fujitsu.com: rewrite comment]
Suggested-by: HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab(a)nec.com>
Signed-off-by: Jackie Liu <liuyun01(a)kylinos.cn>
---
kernel.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/kernel.c b/kernel.c
index 9871637..c8182a6 100644
--- a/kernel.c
+++ b/kernel.c
@@ -10236,7 +10236,7 @@ static struct ikconfig_list {
char *val;
} *ikconfig_all;
-static void add_ikconfig_entry(char *line, struct ikconfig_list *ent)
+static int add_ikconfig_entry(char *line, struct ikconfig_list *ent)
{
char *tokptr, *name, *val;
@@ -10244,8 +10244,16 @@ static void add_ikconfig_entry(char *line, struct ikconfig_list *ent)
sscanf(name, "CONFIG_%s", name);
val = strtok_r(NULL, "", &tokptr);
+ if (!val) {
+ if (CRASHDEBUG(2))
+ error(WARNING, "invalid ikconfig entry: %s\n", line);
+ return FALSE;
+ }
+
ent->name = strdup(name);
ent->val = strdup(val);
+
+ return TRUE;
}
static int setup_ikconfig(char *config)
@@ -10265,8 +10273,8 @@ static int setup_ikconfig(char *config)
ent++;
if (STRNEQ(ent, "CONFIG_")) {
- add_ikconfig_entry(ent,
- &ikconfig_all[kt->ikconfig_ents++]);
+ if (add_ikconfig_entry(ent, &ikconfig_all[kt->ikconfig_ents]))
+ kt->ikconfig_ents++;
if (kt->ikconfig_ents == IKCONFIG_MAX) {
error(WARNING, "ikconfig overflow.\n");
return 1;
--
2.17.1
3 years, 10 months
Re: [Crash-utility] [PATCH] Fixed the segment fault when ikconfig passed nonstandard values
by HAGIO KAZUHITO(萩尾 一仁)
Hi Jackie, Hatayama san,
-----Original Message-----
> 在 2021/1/4 下午1:00, d.hatayama(a)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.
(Thanks for the comment.)
>
>
> Yes, It is.
Could you add more words like the above "entries that do not contain
the delimiter string '='" to the commit message?
>
>
> >
> > 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.
Two or more '=' characters except for the first one will be added to
the value. It can be an arbitrary string, so I think it would be hard
to check if a value is valid or not here.
If we check it, we should do when using the value. But I don't think
the entries that crash uses can break easily..
Thanks,
Kazu
3 years, 10 months
[PATCH] Fixed the segment fault when ikconfig passed nonstandard values
by Jackie Liu
From: Jackie Liu <liuyun01(a)kylinos.cn>
Some strange reasons may cause kcore to collect some strange
entries of ikconfig, such as CONFIG_SECU+[some hex data] causes
the 'val' to be NULL, and then crashes when strdup.
Signed-off-by: Jackie Liu <liuyun01(a)kylinos.cn>
---
kernel.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel.c b/kernel.c
index 9871637..aa86f0d 100644
--- a/kernel.c
+++ b/kernel.c
@@ -10244,6 +10244,9 @@ static void add_ikconfig_entry(char *line, struct ikconfig_list *ent)
sscanf(name, "CONFIG_%s", name);
val = strtok_r(NULL, "", &tokptr);
+ if (!val)
+ return;
+
ent->name = strdup(name);
ent->val = strdup(val);
}
--
2.17.1
3 years, 10 months