From: Bjorn Helgaas <helgaas@kernel.org>
To: Gary Guo <gary@garyguo.net>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
Zhenzhong Duan <zhenzhong.duan@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Danilo Krummrich <dakr@kernel.org>,
Damien Le Moal <dlemoal@kernel.org>,
Niklas Cassel <cassel@kernel.org>,
GOTO Masanori <gotom@debian.or.jp>,
YOKOTA Hiroshi <yokota@netlab.is.tsukuba.ac.jp>,
"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Vaibhav Gupta <vaibhavgupta40@gmail.com>,
Jens Taprogge <jens.taprogge@taprogge.org>,
Ido Schimmel <idosch@nvidia.com>, Petr Machata <petrm@nvidia.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
David Airlie <airlied@redhat.com>,
linux-pci@vger.kernel.org, driver-core@lists.linux.dev,
linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org,
linux-scsi@vger.kernel.org,
industrypack-devel@lists.sourceforge.net, netdev@vger.kernel.org,
dri-devel@lists.freedesktop.org, Sashiko <sashiko-bot@kernel.org>
Subject: Re: [PATCH v3 9/9] pci: fix UAF when probe runs concurrent to dyn ID removal
Date: Thu, 23 Jul 2026 16:10:48 -0500 [thread overview]
Message-ID: <20260723211048.GA857046@bhelgaas> (raw)
In-Reply-To: <DK67INM1MX6H.1FA6WNE8RZ9R7@garyguo.net>
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 <sashiko-bot@kernel.org>
> >> >> Link: https://lore.kernel.org/all/20260619170503.518F61F00A3A@smtp.kernel.org/
> >> >> Fixes: 0994375e9614 ("PCI: add remove_id sysfs entry")
> >> >> Signed-off-by: Gary Guo <gary@garyguo.net>
> >> >> ---
> >> >> 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!
next prev parent reply other threads:[~2026-07-23 21:10 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-06 14:11 [PATCH v3 0/9] pci: fix UAF and TOCTOU related to dynamic ID Gary Guo
2026-07-06 14:11 ` [PATCH v3 1/9] ata: don't store pci_device_id Gary Guo
2026-07-07 1:12 ` Damien Le Moal
2026-07-07 14:12 ` sashiko-bot
2026-07-06 14:11 ` [PATCH v3 2/9] nsp32: " Gary Guo
2026-07-07 14:12 ` sashiko-bot
2026-07-06 14:11 ` [PATCH v3 3/9] ipack: tpci200: " Gary Guo
2026-07-07 14:12 ` sashiko-bot
2026-07-06 14:11 ` [PATCH v3 4/9] mlxsw: " Gary Guo
2026-07-07 14:12 ` sashiko-bot
2026-07-06 14:11 ` [PATCH v3 5/9] agp/via: don't rely on address of pci_device_id Gary Guo
2026-07-07 14:12 ` sashiko-bot
2026-07-06 14:11 ` [PATCH v3 6/9] agp/amd-k7: " Gary Guo
2026-07-07 14:12 ` sashiko-bot
2026-07-06 14:11 ` [PATCH v3 7/9] pci: make pci_match_one_device match on ID instead of device Gary Guo
2026-07-07 14:12 ` sashiko-bot
2026-07-21 22:33 ` Bjorn Helgaas
2026-07-06 14:11 ` [PATCH v3 8/9] pci: fix dyn_id add TOCTOU Gary Guo
2026-07-07 14:12 ` sashiko-bot
2026-07-21 22:34 ` Bjorn Helgaas
2026-07-06 14:11 ` [PATCH v3 9/9] pci: fix UAF when probe runs concurrent to dyn ID removal Gary Guo
2026-07-07 14:12 ` sashiko-bot
2026-07-21 22:35 ` Bjorn Helgaas
2026-07-23 18:57 ` Gary Guo
2026-07-23 19:29 ` Bjorn Helgaas
2026-07-23 19:42 ` Bjorn Helgaas
2026-07-23 19:44 ` Gary Guo
2026-07-23 21:10 ` Bjorn Helgaas [this message]
2026-07-21 13:17 ` [PATCH v3 0/9] pci: fix UAF and TOCTOU related to dynamic ID Gary Guo
2026-07-23 21:21 ` Danilo Krummrich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260723211048.GA857046@bhelgaas \
--to=helgaas@kernel.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=airlied@redhat.com \
--cc=andrew+netdev@lunn.ch \
--cc=bhelgaas@google.com \
--cc=cassel@kernel.org \
--cc=dakr@kernel.org \
--cc=davem@davemloft.net \
--cc=dlemoal@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=driver-core@lists.linux.dev \
--cc=edumazet@google.com \
--cc=gary@garyguo.net \
--cc=gotom@debian.or.jp \
--cc=gregkh@linuxfoundation.org \
--cc=idosch@nvidia.com \
--cc=industrypack-devel@lists.sourceforge.net \
--cc=jens.taprogge@taprogge.org \
--cc=kuba@kernel.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=petrm@nvidia.com \
--cc=rafael@kernel.org \
--cc=sashiko-bot@kernel.org \
--cc=vaibhavgupta40@gmail.com \
--cc=yokota@netlab.is.tsukuba.ac.jp \
--cc=zhenzhong.duan@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox