linux-kernel - Re: [PATCH v3] kconfig: check for a NULL pointer before access

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAEzuVAdu3bDXUGgi4U-XY4dRmBxKaCA_OjKrvK-2ftOWWwVEYA@mail.gmail.com>
Date: Mon, 26 May 2025 01:08:06 -0700
From: Bill Wendling <isanbard@...il.com>
To: Masahiro Yamada <masahiroy@...nel.org>
Cc: Bill Wendling <morbo@...gle.com>, 
	Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, 
	Randy Dunlap <rdunlap@...radead.org>
Subject: Re: [PATCH v3] kconfig: check for a NULL pointer before access

On Sat, May 24, 2025 at 10:08 AM Masahiro Yamada <masahiroy@...nel.org> wrote:
>
> On Sat, May 24, 2025 at 9:49 AM Bill Wendling <isanbard@...il.com> wrote:
> >
> > The call to 'prop_get_symbol' may return NULL in some cases. The if-then
> > statement accesses the returned value without cheecking if it's
> > non-NULL. After inlining, the compiler may treat the conditional as
> > 'undefined behavior', which the compiler may take the opportunity to do
> > whatever it wants with the UB path. This patch simply adds a check to
> > ensure that 'def_sym' is non-NULL to avoid this behavior.
> >
> > Signed-off-by: Bill Wendling <isanbard@...il.com>
>
> Same reaction to this patch
>
> https://lore.kernel.org/linux-kbuild/20250212154537.235297-1-ant.v.moryakov@gmail.com/
>
I apologize for the whitespace problems. My mailer is crap and
sendmail isn't available on my local machine (it's a long story).

> Please attach a test case
> that causes a segfault with NULL pointer dereference.
>
I don't have a testcase. I discovered this while working on a Clang
feature to isolate paths with undefined behavior. (GCC already has
this pass.) The compiler notices that, after inlining, the path has
UB. It's not necessarily important whether the current compiler messes
up the code path, it's more a matter of *when* the compiler will mess
up the code path, as marking UB paths as "not executable therefore not
executed" is a common trope for some compiler developers.

-bw