Re: [PATCH] ACPI: PCI: Clear driver_data on all error paths in acpi_pci_root_add()

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The acpi_pci_root_remove() function frees the acpi_pci_root object but fails to clear device->driver_data, leaving a dangling pointer.
- [High] Lockless access to `device->driver_data` causes a TOCTOU Use-After-Free race during hot-add failure and hot-remove.
--

--- Patch [1]: [PATCH] ACPI: PCI: Clear driver_data on all error paths in acpi_pci_root_add() ---
commit 9ff3c7d0724a7259ad865b11b68825024947383a
Author: Chen Pei <cp0613@linux.alibaba.com>

ACPI: PCI: Clear driver_data on all error paths in acpi_pci_root_add()

This commit addresses a dangling pointer issue in acpi_pci_root_add() by
ensuring device->driver_data is set to NULL on all error paths before
freeing the root object. This prevents use-after-free conditions during a
failed hot-add operation.

Link: https://sashiko.dev/#/patchset/20260526025118.38935-1-cp0613@linux.alibaba.com

> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index 4c06c3ffd0cbb..f6cddd11075cb 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c

[ ... ]

> @@ -765,6 +764,7 @@ static int acpi_pci_root_add(struct acpi_device *device,
>  	if (hotadd)
>  		dmar_device_remove(handle);
>  end:
> +	device->driver_data = NULL;
>  	kfree(root);

[Severity: High]
This isn't a bug introduced by this patch, but does this lockless cleanup
introduce a use-after-free race with concurrent readers?

If acpi_pci_root_add() publishes the root pointer early:

        device->driver_data = root;

and a concurrent thread (e.g., AER or CXL probe) calls
acpi_pci_find_root() and locklessly reads this pointer:

drivers/acpi/pci_root.c:acpi_pci_find_root() {
        ...
        root = acpi_driver_data(device);
        ...
}

Could that concurrent reader dereference a freed pointer if
acpi_pci_root_add() subsequently encounters an error, clears
device->driver_data, and executes kfree(root) here without an RCU
grace period or locking to synchronize the read and the free?

[Severity: High]
This is also a pre-existing issue, but while we are fixing the error paths
here, does acpi_pci_root_remove() have the same dangling pointer
vulnerability that this patch fixes for the add path?

Looking at acpi_pci_root_remove(), it appears to free the acpi_pci_root
object but fails to clear device->driver_data:

drivers/acpi/pci_root.c:acpi_pci_root_remove() {
        ...
        kfree(root);
        ...
}

If a PCI root bridge is hot-removed and another subsystem later calls
acpi_pci_find_root(), could it locklessly read the dangling pointer
and dereference it?

>  	return result;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260707121258.11640-1-cp0613@linux.alibaba.com?part=1