Re: [PATCH 4/9] PCI: brcmstb: Protect root bus removal with rescan lock

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Calling `brcm_pcie_remove()` on the `pci_host_probe()` error path triggers a Use-After-Free (UAF) or NULL pointer dereference.
- [High] The `pcie->bridge_lock` is used before it is initialized during device probe.
--

commit baacf34014bfc48de11be2860d0ae507bf20e383
Author: Hans Zhang <18255117159@163.com>

PCI: brcmstb: Protect root bus removal with rescan lock

Add missing PCI rescan lock protection in brcm_pcie_remove() before
removing the root bus.

> diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
> index 714bcab97b603..7ca27f0756c9b 100644
> --- a/drivers/pci/controller/pcie-brcmstb.c
> +++ b/drivers/pci/controller/pcie-brcmstb.c
> @@ -1894,8 +1894,10 @@ static void brcm_pcie_remove(struct platform_device *pdev)
>  	struct brcm_pcie *pcie = platform_get_drvdata(pdev);
>  	struct pci_host_bridge *bridge = pci_host_bridge_from_priv(pcie);
>  
> +	pci_lock_rescan_remove();
>  	pci_stop_root_bus(bridge->bus);

[Severity: Critical]
This is a pre-existing issue, but can calling brcm_pcie_remove() on the
pci_host_probe() error path trigger a use-after-free or null pointer
dereference here?

In brcm_pcie_probe(), if pci_host_probe() fails, the error path directly
calls brcm_pcie_remove(). If pci_host_probe() failed early because
pci_alloc_bus() returned null, bridge->bus remains null. If it failed later
during pci_register_host_bridge(), the allocated bus is freed via kfree(),
but bridge->bus is never cleared, leaving it as a dangling pointer.

When brcm_pcie_remove() is invoked, it unconditionally calls
pci_stop_root_bus(bridge->bus). Passing a null or dangling pointer here
causes a kernel crash on the probe error path.

>  	pci_remove_root_bus(bridge->bus);
> +	pci_unlock_rescan_remove();
>  	if (pcie->cfg->has_err_report)
>  		brcm_unregister_die_notifiers(pcie);

[Severity: High]
This is a pre-existing issue, but is pcie->bridge_lock used before it is
initialized during device probe?

During brcm_pcie_probe(), the function brcm_pcie_bridge_sw_init_set() is
called early in the initialization sequence. For devices where
pcie->cfg->has_err_report is true, this function acquires pcie->bridge_lock
via spin_lock_irqsave().

However, spin_lock_init(&pcie->bridge_lock) is not called until much later
in the probe sequence, after pci_host_probe() finishes. While the memory is
zero-initialized, unconditionally attempting to acquire an uninitialized
spinlock is structurally unsafe and can trigger lockdep warnings or crashes.

>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260521161822.132996-1-18255117159@163.com?part=4