CVE-2026-92521 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
ACPI: PCI: Clear driver_data on all paths that free the acpi_pci_root
acpi_pci_root_add() assigns the freshly allocated root to device->driver_data before dmar_device_add() and pci_acpi_scan_root(). Both failure paths reach the end: label where root is kfree()'d, but only the pci_acpi_scan_root() path clears driver_data first.
When dmar_device_add() fails during a hot-add, root is freed while device->driver_data still points at it. The ACPI core does not clear driver_data on attach failure, so a later acpi_pci_find_root() call may dereference this dangling pointer.
acpi_pci_root_remove() has the same problem: it frees root without clearing device->driver_data, leaving a dangling pointer behind after the root bridge is removed.
Move the NULL assignment to the shared end: label so every error path in acpi_pci_root_add() clears driver_data before freeing root, and clear it in acpi_pci_root_remove() as well, so the object is never left reachable through driver_data after being freed.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The identified vulnerability resides within the ACPI PCI subsystem of the Linux kernel, specifically affecting the management lifecycle of ACPI PCI roots during device initialization and removal operations. The core technical flaw involves improper handling of the driver_data pointer associated with struct acpi_device objects when memory allocation or subsequent setup functions fail. In normal operation, the function acpi_pci_root_add allocates a new root structure and assigns its address to device->driver_data before invoking helper functions such as dmar_device_add for DMA remapping initialization and pci_acpi_scan_root for PCI bus scanning. However, if either of these downstream calls fails, control flow jumps to an error handling label where the allocated root is freed via kfree. Crucially, in several failure paths within acpi_pci_root_add, specifically those originating from dmar_device_add failures during hot-add scenarios, the driver_data pointer is not cleared before the memory is released. This oversight leaves a dangling pointer that still references the now-deallocated memory region.
This condition creates a significant risk of use-after-free vulnerabilities and potential kernel crashes or privilege escalation if an attacker can trigger these failure paths repeatedly or manipulate system state to induce them. The ACPI core does not automatically clear driver_data upon attachment failures, meaning the stale reference persists in the device structure. Subsequent calls to acpi_pci_find_root may attempt to dereference this dangling pointer, leading to undefined behavior. Furthermore, the issue is compounded by a similar deficiency in acpi_pci_root_remove, which frees the root structure without nullifying the corresponding driver_data field after a bridge removal event. This leaves the system vulnerable even during normal teardown operations if subsequent lookups occur before proper cleanup or if race conditions allow access to freed memory.
From a security taxonomy perspective, this vulnerability aligns with CWE-416, Use After Free, as it involves accessing memory that has been deallocated but not properly invalidated in all references. The attack vector typically requires local privilege escalation capabilities to trigger the specific ACPI hot-add or removal sequences that lead to the error paths, although remote exploitation is theoretically possible if ACPI events can be triggered remotely via managed hardware interfaces. In terms of MITRE ATT&CK mapping, this falls under T1203 Exploitation for Defense Evasion and potentially T1059 Command and Scripting Interpreter if used in conjunction with other kernel exploits to gain execution control. The lack of atomicity or proper pointer nullification represents a classic memory safety error common in systems programming where resource cleanup is not uniformly applied across all code paths.
To mitigate this vulnerability, the Linux kernel developers have implemented a fix that centralizes the clearing of driver_data. By moving the NULL assignment to a shared end label within acpi_pci_root_add, every exit path now ensures that device->driver_data is set to NULL before kfree is called on the root structure. Additionally, acpi_pci_root_remove has been updated to explicitly clear this pointer upon bridge removal. This change guarantees that no dangling pointers remain accessible through the ACPI device structure after memory deallocation. System administrators should ensure their kernels are patched with versions containing these specific commits in the ACPI PCI subsystem. Regular kernel updates and applying security patches promptly is essential to prevent exploitation of such low-level memory management flaws, which can otherwise serve as footholds for deeper system compromise.