linux-kernel - Re: [PATCH] driver core: Don't match device with NULL of

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: <Z1eBotg2DiaXLWqn@google.com>
Date: Mon, 9 Dec 2024 15:47:46 -0800
From: Brian Norris <briannorris@...omium.org>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: "Rob Herring (Arm)" <robh@...nel.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] driver core: Don't match device with NULL of_node/fwnode

Hi Greg,

On Wed, Dec 04, 2024 at 10:37:06AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Dec 03, 2024 at 06:02:59PM -0600, Rob Herring (Arm) wrote:
> > It recently came up that of_find_device_by_node() will match a device
> > with a NULL of_node pointer. This is not desired behavior. The returned
> > struct device is also not deterministic.
> 
> It's not deterministic because a NULL pointer will cause that to happen,
> or for some other reason?

It'll pick the first platform device with no of_node. That likely yields
something very wrong, but doesn't produce a visible problem until a
caller does something with the result. Commit 5c8418cf4025
("PCI/pwrctrl: Unregister platform device only if one actually exists")
has plenty of explanation of what really goes wrong.

> > Cc: Bjorn Helgaas <bhelgaas@...gle.com>
> > Signed-off-by: Rob Herring (Arm) <robh@...nel.org>
> > ---
> > It would be a bit more efficient to check this up front before we
> > iterate thru devices, but there's a number of users of these functions
> > and this isn't really a hot path.
> 
> Yeah, this should be fine.  Does this fix a problem now and we need it
> merged for 6.13-final and backported, or can it just wait for 6.14-rc1?

It's a preventive measure to help head off future confusing bugs. It
doesn't need expedited merging or backporting.

FWIW, last week, I also cooked this change locally (+ the ACPI change;
and a kunit test for added fun), before I noticed Rob submitted this
one. If you'd rather, I can submit my patch series. Or I can submit my
patch series on top of this. Whichever you'd prefer.

Brian