CVE-2026-93251: ACPI: bus: Introduce acpi_bus_get_primary_device()
ACPI: bus: Introduce acpibusgetprimarydevice()
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.114 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.57 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.6 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.6-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.12-1Fixed in 7.2.14-1
Event History
Frequently Asked Questions
What race condition is addressed by this change?
A caller can obtain a physical-device pointer from acpi_get_first_physical_node() after the ACPI device lock has been released. acpi_unbind_one() may then complete and drop the final reference to that physical device before the caller invokes get_device(), resulting in a use-after-free.
Which code paths are most relevant to the issue?
The issue affects callers of acpi_get_first_physical_node() that subsequently call get_device() on the returned pointer, which the description says is the majority of its callers. The new acpi_bus_get_primary_device() function obtains a reference before returning the primary physical-device pointer.
How does the resolved implementation prevent the use-after-free?
It introduces acpi_bus_get_primary_device(), which reference-counts the associated primary physical device before returning it to the caller. This prevents the device from being freed in the interval between list lookup and the caller acquiring its own reference.