Re: [PATCH v3 9/9] pci: fix UAF when probe runs concurrent to dyn ID removal

On Thu Jul 23, 2026 at 8:29 PM BST, Bjorn Helgaas wrote:
> On Thu, Jul 23, 2026 at 07:57:58PM +0100, Gary Guo wrote:
>> On Tue Jul 21, 2026 at 11:35 PM BST, Bjorn Helgaas wrote:
>> > On Mon, Jul 06, 2026 at 03:11:21PM +0100, Gary Guo wrote:
>> >> Dynamic IDs are only guaranteed to be valid when dynids.lock is held,
>> >> as remove_id_store can free the node. Thus, make a copy in
>> >> pci_match_device. Also, clarify that the id parameter is only valid d=
uring
>> >> probe.
>> >>=20
>> >> Reported-by: Sashiko <[email protected]>
>> >> Link: https://lore.kernel.org/all/[email protected]=
rnel.org/
>> >> Fixes: 0994375e9614 ("PCI: add remove_id sysfs entry")
>> >> Signed-off-by: Gary Guo <[email protected]>
>> >> ---
>> >>  drivers/pci/pci-driver.c | 28 +++++++++++++++-------------
>> >>  include/linux/pci.h      |  1 +
>> >>  2 files changed, 16 insertions(+), 13 deletions(-)
>> >>=20
>> >> diff --git a/include/linux/pci.h b/include/linux/pci.h
>> >> index 64b308b6e61c..92c17c116de6 100644
>> >> --- a/include/linux/pci.h
>> >> +++ b/include/linux/pci.h
>> >> @@ -979,6 +979,7 @@ struct module;
>> >>   *		function returns zero when the driver chooses to
>> >>   *		take "ownership" of the device or an error code
>> >>   *		(negative number) otherwise.
>> >> + *		The pci_device_id parameter is only valid during probe.
>> >
>> > The probe function takes a pointer to a struct pci_device_id, so I
>> > think the requirement is that the struct pci_device_id only *needs* to
>> > be valid during .probe(), right, i.e., the PCI core probe path makes
>> > its own copy of the ID and doesn't retain the pointer after .probe()
>> > returns, right?
>> >
>> > I assume the caller determines the struct pci_device_id lifetime, and
>> > it could be forever.
>> >
>> > Could say something like:
>> >
>> >   The pci_device_id parameter only needs to be valid during probe.
>>=20
>> As a contract on function parameter, the caller needs to guarantee that =
it lives
>> at least as long as documented (i.e. during the whole probe) and the cal=
lee
>> cannot assume that it will be valid beyond what's guaranteed.
>>=20
>> How about:
>>=20
>>     The pci_device_id parameter is only guaranteed to be valid during pr=
obe.
>
> That's ok with me.  My only niggle is that this documentation is that the
> *consumer* end, and of course the consumer, i.e., the PCI core probe path=
,
> can't guarantee anything about the parameters it receives.  But I guess
> your point is that the *caller* must guarantee that the parameter remains
> valid during probe.

I'm not quite getting it, the PCI core probe path is pci-driver.c which is =
the
caller? Do you mean that the PCI *driver* probe path cannot guarantee anyth=
ing
about the parameter it receives?

>
> The only thing the consumer can guarantee is that it doesn't depend on th=
e
> pci_device_id parameter after the probe returns.

How about:

    The pci_device_id parameter may not be valid after the probe returns an=
d
    must not be used afterwards.

Best,
Gary