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: <CAL_Jsq+5cQHqoJ9wAgt0moU94Bddgsw+Q3TEWDqQ+-rryJPS1Q@mail.gmail.com>
Date: Tue, 10 Dec 2024 06:33:05 -0600
From: Rob Herring <robh@...nel.org>
To: Brian Norris <briannorris@...omium.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.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

On Mon, Dec 9, 2024 at 5:47 PM Brian Norris <briannorris@...omium.org> wrote:
>
> 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.

If you have a kunit test, you win. :)

Rob