linux-kernel - Re: [PATCH] driver core: faux: fix Undefined Behavior in faux_device

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <a3a08e5d-bfea-4569-8d13-ed0a42d81b2a@linux.intel.com>
Date: Sat, 14 Jun 2025 07:53:34 -0700
From: Marc Herbert <marc.herbert@...ux.intel.com>
To: Greg KH <gregkh@...uxfoundation.org>, Miguel Ojeda <ojeda@...nel.org>
Cc: Benjamin.Cheatham@....com, Jonathan.Cameron@...wei.com, dakr@...nel.org,
 dan.j.williams@...el.com, linux-acpi@...r.kernel.org,
 linux-cxl@...r.kernel.org, linux-kernel@...r.kernel.org,
 rafael.j.wysocki@...el.com, rafael@...nel.org, sudeep.holla@....com,
 Dan Carpenter <dan.carpenter@...aro.org>, Kees Cook <kees@...nel.org>
Subject: Re: [PATCH] driver core: faux: fix Undefined Behavior in
 faux_device_destroy()

> the kernel relies on this not being "optimized away" by the compiler
> in many places.

I think "undefined behavior" is the more general topic, more important
than null pointer checks specifically?

> the kernel relies on the compiler to be sane :)

Undefined behavior is... insane by essence? I'm afraid a few custom
compiler options can never fully address that.  While we might get away
with -fno-delete-null-pointer-checks right here right now, who knows
what else could happen in some future compiler version or future
combination of flags. No one: that's why it's called "undefined"
behavior!

> If "tooling" trips over stuff like this, then we should fix the tooling

Because of its old age, many quirks and limitations, C needs and has a
pretty large number of external "tools": static and run-time analyzers,
coding rules (CERT, MISRA,...) and what not. It's not realistic to "fix"
them all so they all "support" undefined behaviors like this one. It's
already hard enough for them to agree on false positives with a somewhat
"standard" version of C. The kernel wields a massive influence but
I'm afraid its power is not big enough to impose its own C "flavor". It
has influence on gcc and a couple others but not on the language as a
whole. The alternative is for the kernel to stay incompatible by choice
with most C "tooling" available - and find fewer issues :-(

(For even more diverse language mess, take a look at the Safe C++
"standardization" attempt and at C++ "profiles". I digress)

> I see a similar case with discussion at:
> https://lore.kernel.org/lkml/3f1e7aaa-501a-44f1-8122-28e9efa0a33c@web.de/

Thanks Miguel for these near-identical examples. While more verbose and more
error-prone, this can indeed be fixed with pre-C99, separate definitions
as it was done in multiple places there.

This is just moving one line of code a few lines down. I think there are
many more "interesting" and much more complex C flaws to waste time on :-)
My 2 cents.