Re: [PATCH v19 6/7] PCI: Enable async shutdown support

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but there is a double-put bug in `pci_register_host_bridge()`'s error handling path when `device_register(&bus->dev)` fails, leading to a Use-After-Free and Double Free on the host bridge device.
--

--- Patch [6]: [PATCH v19 6/7] PCI: Enable async shutdown support ---
commit bf029d21ad5b4df727aa0c1ae7b24c789b0e433a
Author: David Jeffery <djeffery@redhat.com>

PCI: Enable async shutdown support

Like its async suspend support, allow PCI device shutdown to be performed
asynchronously to reduce shutdown time.

> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index dd0abbc63e18d..af23814464060 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1046,6 +1046,7 @@ static int pci_register_host_bridge(struct pci_host_bridge *bridge)
>  
>  	bus->bridge = get_device(&bridge->dev);
>  	device_enable_async_suspend(bus->bridge);
> +	dev_set_async_shutdown(bus->bridge);
>  	pci_set_bus_of_node(bus);
>  	pci_set_bus_msi_domain(bus);

[Severity: High]
This problem wasn't introduced by this patch, but there appears to be a
pre-existing double-put bug in pci_register_host_bridge() when handling
registration failures.

Further down in pci_register_host_bridge(), if device_register(&bus->dev)
fails, the code jumps to the unregister label:

unregister:
        put_device(&bridge->dev);
        device_del(&bridge->dev);
free:

Does this path drop the caller's initial reference prematurely?

In the free block, because bus_registered is true, it calls
put_device(&bus->dev). The device's release function (release_pcibus_dev)
explicitly calls put_device(pci_bus->bridge), dropping the reference
correctly taken by bus->bridge = get_device(&bridge->dev).

Because the unregister block explicitly drops the caller's initial reference
early, the bridge is freed. The function then returns an error to the caller,
which will likely call put_device(&bridge->dev) to clean up its initial
reference.

Can this sequence cause a double-free and use-after-free on the already freed
bridge pointer?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260716230411.2767394-1-tarunsahu@google.com?part=6