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: <2025061546-exile-baggage-c231@gregkh>
Date: Sun, 15 Jun 2025 23:35:10 -0400
From: Greg KH <gregkh@...uxfoundation.org>
To: Marc Herbert <marc.herbert@...ux.intel.com>
Cc: Miguel Ojeda <ojeda@...nel.org>, 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()

On Sat, Jun 14, 2025 at 07:53:34AM -0700, Marc Herbert wrote:
> > 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?

Is this really "undefined behaviour"?  There are a lot of things that
the kernel requires for a compiler to be able to build it, and this is
one of those things, it can't do this type of "optimization" and expect
the output to actually work properly.

> > 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!

Again, that's not the issue here.  The issue is that we rely on this
type of optimization to not happen in order to work properly.  So no
need to "fix" anything here except perhaps the compiler for not
attempting to do foolish things like this :)

> > 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.

If they wish to analize Linux, then yes, they do need to be fixed to
recognize that this is not an issue for us.  There is no requirement
that we have that _all_ tools must be able to parse our source code.

thanks,

greg k-h