From: Libo Chen <clbchenlibo.chen@huawei.com>
To: Li Zefan <lizefan@huawei.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Michal Marek <mmarek@suse.cz>,
Weng Meiling <wengmeiling.weng@huawei.com>,
LKML <linux-kernel@vger.kernel.org>,
linux-kbuild@vger.kernel.org, Borislav Petkov <bp@alien8.de>
Subject: Re: [PATCH] menuconfig: fix NULL pointer dereference when searching a symbol
Date: Tue, 7 May 2013 10:48:48 +0800 [thread overview]
Message-ID: <51886B90.8060502@huawei.com> (raw)
In-Reply-To: <518869BB.2020808@huawei.com>
On 2013/5/7 10:40, Li Zefan wrote:
> Searching PPC_EFIKA results segmentation fault, and it's because
> get_symbol_prop() returns NULL.
>
> In this case CONFIG_PPC_EFIKA is defined in arch/powerpc/platforms/
> 52xx/Kconfig, so it won't be parsed if ARCH!=PPC, but menuconfig
> knows this symbol when it parses sound/soc/fsl/Kconfig:
>
> config SND_MPC52xx_SOC_EFIKA
> tristate "SoC AC97 Audio support for bbplan Efika and STAC9766"
> depends on PPC_EFIKA
>
> This bug was introduced by commit bcdedcc1afd6 ("menuconfig: print more
> info for symbol without prompts").
It works!
Tested-by: Libo Chen <libo.chen@huawei.com>
>
> Reported-by: Borislav Petkov <bp@alien8.de>
> Signed-off-by: Li Zefan <lizefan@huawei.com>
> ---
> scripts/kconfig/menu.c | 16 ++++++++++------
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
> index 826da66..b5c7d90 100644
> --- a/scripts/kconfig/menu.c
> +++ b/scripts/kconfig/menu.c
> @@ -600,14 +600,18 @@ void get_symbol_str(struct gstr *r, struct symbol *sym,
> }
> for_all_prompts(sym, prop)
> get_prompt_str(r, prop, head);
> +
> prop = get_symbol_prop(sym);
> - str_printf(r, _(" Defined at %s:%d\n"), prop->menu->file->name,
> - prop->menu->lineno);
> - if (!expr_is_yes(prop->visible.expr)) {
> - str_append(r, _(" Depends on: "));
> - expr_gstr_print(prop->visible.expr, r);
> - str_append(r, "\n");
> + if (prop) {
> + str_printf(r, _(" Defined at %s:%d\n"), prop->menu->file->name,
> + prop->menu->lineno);
> + if (!expr_is_yes(prop->visible.expr)) {
> + str_append(r, _(" Depends on: "));
> + expr_gstr_print(prop->visible.expr, r);
> + str_append(r, "\n");
> + }
> }
> +
> hit = false;
> for_all_properties(sym, prop, P_SELECT) {
> if (!hit) {
>
WARNING: multiple messages have this Message-ID (diff)
From: Libo Chen <clbchenlibo.chen@huawei.com>
To: Li Zefan <lizefan@huawei.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Michal Marek <mmarek@suse.cz>,
Weng Meiling <wengmeiling.weng@huawei.com>,
LKML <linux-kernel@vger.kernel.org>,
<linux-kbuild@vger.kernel.org>, Borislav Petkov <bp@alien8.de>
Subject: Re: [PATCH] menuconfig: fix NULL pointer dereference when searching a symbol
Date: Tue, 7 May 2013 10:48:48 +0800 [thread overview]
Message-ID: <51886B90.8060502@huawei.com> (raw)
In-Reply-To: <518869BB.2020808@huawei.com>
On 2013/5/7 10:40, Li Zefan wrote:
> Searching PPC_EFIKA results segmentation fault, and it's because
> get_symbol_prop() returns NULL.
>
> In this case CONFIG_PPC_EFIKA is defined in arch/powerpc/platforms/
> 52xx/Kconfig, so it won't be parsed if ARCH!=PPC, but menuconfig
> knows this symbol when it parses sound/soc/fsl/Kconfig:
>
> config SND_MPC52xx_SOC_EFIKA
> tristate "SoC AC97 Audio support for bbplan Efika and STAC9766"
> depends on PPC_EFIKA
>
> This bug was introduced by commit bcdedcc1afd6 ("menuconfig: print more
> info for symbol without prompts").
It works!
Tested-by: Libo Chen <libo.chen@huawei.com>
>
> Reported-by: Borislav Petkov <bp@alien8.de>
> Signed-off-by: Li Zefan <lizefan@huawei.com>
> ---
> scripts/kconfig/menu.c | 16 ++++++++++------
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
> index 826da66..b5c7d90 100644
> --- a/scripts/kconfig/menu.c
> +++ b/scripts/kconfig/menu.c
> @@ -600,14 +600,18 @@ void get_symbol_str(struct gstr *r, struct symbol *sym,
> }
> for_all_prompts(sym, prop)
> get_prompt_str(r, prop, head);
> +
> prop = get_symbol_prop(sym);
> - str_printf(r, _(" Defined at %s:%d\n"), prop->menu->file->name,
> - prop->menu->lineno);
> - if (!expr_is_yes(prop->visible.expr)) {
> - str_append(r, _(" Depends on: "));
> - expr_gstr_print(prop->visible.expr, r);
> - str_append(r, "\n");
> + if (prop) {
> + str_printf(r, _(" Defined at %s:%d\n"), prop->menu->file->name,
> + prop->menu->lineno);
> + if (!expr_is_yes(prop->visible.expr)) {
> + str_append(r, _(" Depends on: "));
> + expr_gstr_print(prop->visible.expr, r);
> + str_append(r, "\n");
> + }
> }
> +
> hit = false;
> for_all_properties(sym, prop, P_SELECT) {
> if (!hit) {
>
next prev parent reply other threads:[~2013-05-07 2:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-07 2:40 [PATCH] menuconfig: fix NULL pointer dereference when searching a symbol Li Zefan
2013-05-07 2:40 ` Li Zefan
2013-05-07 2:48 ` Libo Chen [this message]
2013-05-07 2:48 ` Libo Chen
2013-05-07 10:44 ` Borislav Petkov
2013-05-07 13:21 ` Yann E. MORIN
2013-05-07 13:47 ` Michal Marek
2013-05-07 14:06 ` Yann E. MORIN
2013-05-07 14:13 ` Michal Marek
-- strict thread matches above, loose matches on Subject: below --
2013-05-07 13:56 Michal Marek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51886B90.8060502@huawei.com \
--to=clbchenlibo.chen@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan@huawei.com \
--cc=mmarek@suse.cz \
--cc=wengmeiling.weng@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.