Netdev List
 help / color / mirror / Atom feed
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!

  reply	other threads:[~2026-07-23 21:10 UTC|newest]

Thread overview: 21+ 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-06 14:11 ` [PATCH v3 2/9] nsp32: " Gary Guo
2026-07-06 14:11 ` [PATCH v3 3/9] ipack: tpci200: " Gary Guo
2026-07-06 14:11 ` [PATCH v3 4/9] mlxsw: " Gary Guo
2026-07-06 14:11 ` [PATCH v3 5/9] agp/via: don't rely on address of pci_device_id Gary Guo
2026-07-06 14:11 ` [PATCH v3 6/9] agp/amd-k7: " Gary Guo
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-21 22:33   ` Bjorn Helgaas
2026-07-06 14:11 ` [PATCH v3 8/9] pci: fix dyn_id add TOCTOU Gary Guo
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-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