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

On Thu, Jul 23, 2026 at 08:44:48PM +0100, Gary Guo wrote:
> 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 during
> >> >> probe.
> >> >> 
> >> >> Reported-by: Sashiko <[email protected]>
> >> >> Link: https://lore.kernel.org/all/[email protected]/
> >> >> 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(-)
> >> >> 
> >> >> 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.
> >> 
> >> 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 callee cannot assume that it will
> >> be valid beyond what's guaranteed.
> >> 
> >> How about:
> >> 
> >>     The pci_device_id parameter is only guaranteed to be valid
> >>     during probe.
> >
> > 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 anything about the parameter it receives?
> 
> > The only thing the consumer can guarantee is that it doesn't
> > depend on the pci_device_id parameter after the probe returns.
> 
> How about:
> 
>     The pci_device_id parameter may not be valid after the probe
>     returns and must not be used afterwards.

You're right, sorry, I had this all completely backwards.  I was
thinking the pci_device_id came from a PCI endpoint driver, but of
course that's not right.  The PCI core *supplies* it to the driver's
.probe() function, and that .probe() shouldn't save the pointer.

I think either your original text or your last proposal is fine.

Sorry for confusing all this!