From: "Li,Rongqing" <lirongqing@baidu.com>
To: "sashiko-reviews@lists.linux.dev"
<sashiko-reviews@lists.linux.dev>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: 答复: [外部邮件] Re: [PATCH] PCI: Clear the bridge's subordinate pointer when child bus registration fails
Date: Tue, 10 Nov 2026 08:16:09 +0000 [thread overview]
Message-ID: <2638cdcc09a04f609c671eab9eea0129@baidu.com> (raw)
In-Reply-To: <sashiko-outbox-206355@kernel.org>
>
> commit 145a85e5894672f4949013776fe03b0bdc6734a5
> Author: Li RongQing <lirongqing@baidu.com>
>
> > PCI: Clear the bridge's subordinate pointer when child bus
> > registration fails
> >
> > pci_alloc_child_bus() stores the new bus in bridge->subordinate before
> > device_register(&child->dev). If registration fails,
> > put_device(&child->dev) runs release_pcibus_dev() and frees the bus,
> > but
> > bridge->subordinate still points at it.
> >
> > The caller returns without scanning the new bus, yet the rest of the
> > rescan or removal path still follows dev->subordinate:
> > pci_assign_unassigned_bridge_resources() and pci_stop_bus_device()
> > walk
> > bus->devices of the freed bus.
> >
> > Clear the pointer before dropping the reference.
> >
> > Signed-off-by: Li RongQing <lirongqing@baidu.com>
>
> [Severity: Low]
> Since 1f2768b6a3ee ("PCI: Fix reference leak in pci_alloc_child_bus()") added
> the put_device(&child->dev) call that frees child on registration failure without
> clearing bridge->subordinate, should this include:
>
> Fixes: 1f2768b6a3ee ("PCI: Fix reference leak in pci_alloc_child_bus()")
>
I think this issue has limited impact, so I didn't add a Fixes tag. Please, maintainer, check whether a Fixes tag is needed.
> > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index
> > 222ad696a1581..efa85ae052106 100644
> > --- a/drivers/pci/probe.c
> > +++ b/drivers/pci/probe.c
> > @@ -1271,6 +1271,8 @@ static struct pci_bus *pci_alloc_child_bus(struct
> pci_bus *parent,
> > pci_set_bus_msi_domain(child);
> > ret = device_register(&child->dev);
> > if (WARN_ON(ret < 0)) {
> > + if (bridge)
> > + bridge->subordinate = NULL;
> > put_device(&child->dev);
> > return NULL;
> > }
>
> [Severity: Critical]
> This problem wasn't introduced by this patch, but does
> pci_register_host_bridge() [1] drop bridge->dev twice when
> device_register(&bus->dev) fails?
>
> pci_register_host_bridge() takes a second reference to bridge->dev via
> bus->bridge = get_device(&bridge->dev). When device_register(&bus->dev)
> fails, the error path jumps to unregister, which calls
> put_device(&bridge->dev) and then put_device(&bus->dev):
>
> drivers/pci/probe.c:pci_register_host_bridge() {
> ...
> bus->bridge = get_device(&bridge->dev);
> ...
> err = device_register(&bus->dev);
> bus_registered = true;
> if (err)
> goto unregister;
> ...
> unregister:
> put_device(&bridge->dev);
> device_del(&bridge->dev);
> free:
> ...
> if (bus_registered)
> put_device(&bus->dev);
> }
>
> Because put_device(&bus->dev) invokes release_pcibus_dev(), which calls
> put_device(pci_bus->bridge), both references to bridge->dev are dropped and
> the host bridge is freed before returning to the caller. When a caller such as
> pci_create_root_bus() then calls put_device(&bridge->dev) on its own error path,
> it triggers a use-after-free and double put.
>
> [1] https://sashiko.dev/#/bug/linux-274884f5-d0c4-48cf-95bc-82c1e0b3753d
>
The issue reported by Sashiko has already been addressed by the below submit:
.
https://patchwork.kernel.org/project/linux-pci/patch/20261019161636.2540334-1-nirmoyd@nvidia.com/
Thanks
Li RongQing
> --
> Sashiko AI
> review · https://sashiko.dev/#/patchset/20261110053410.2469-1-lirongqing
> @baidu.com?part=1
prev parent reply other threads:[~2026-11-10 8:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-10 5:34 [PATCH] PCI: Clear the bridge's subordinate pointer when child bus registration fails lirongqing
2026-11-10 5:56 ` sashiko-bot
2026-11-10 8:16 ` Li,Rongqing [this message]
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=2638cdcc09a04f609c671eab9eea0129@baidu.com \
--to=lirongqing@baidu.com \
--cc=linux-pci@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.