Cloudanix VulnDB

CVE-2026-92521

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in how the Linux kernel manages certain hardware connection data can leave old references after cleanup, risking crashes or unauthorized access on affected machines.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free via dangling pointer in device->driver_data after acpi_pci_root kfree on dmar_device_add failure or acpi_pci_root_remove paths, allowing later acpi_pci_find_root dereference of freed memory.

Why it matters to the business

Linux systems may experience kernel crashes, memory corruption, or potential local privilege escalation during PCI hot-add/remove operations, increasing downtime and security exposure on servers and embedded devices; low exploit maturity and stable low EPSS indicate limited immediate widespread risk 37 days after publication.

How an attack unfolds

An attacker with local access triggers acpi_pci_root_add failure in dmar_device_add during simulated hot-add, or invokes acpi_pci_root_remove; the freed root remains referenced via driver_data, and a subsequent acpi_pci_find_root call dereferences the dangling pointer to achieve use-after-free.

How to fix it

Apply the upstream kernel commit that moves NULL assignment to the shared end label in acpi_pci_root_add and clears driver_data in acpi_pci_root_remove; rebuild and deploy updated kernel packages across all affected distributions.

How to confirm the fix worked

Confirm the fix by inspecting acpi_pci_root_add and acpi_pci_root_remove for driver_data=NULL before kfree, then test hot-add/remove cycles and verify absence of dangling pointer dereferences via kernel debug or static analysis.

Typical attack path

  1. Gain local execution on target Linux system
  2. Trigger PCI root hot-add or removal path that exercises dmar_device_add failure or root removal
  3. Leave device->driver_data pointing to kfree'd acpi_pci_root
  4. Invoke acpi_pci_find_root to dereference freed memory for corruption or control flow hijack

How to detect it

Search kernel logs for ACPI PCI root allocation/free patterns around hot-add or removal events; correlate with oops or panic traces involving acpi_pci_find_root or driver_data dereferences; no named threat actors or ransomware campaigns associated.

What your security team should do

  • Prioritize kernel updates on systems performing frequent PCI hot-plug operations
  • Monitor for new stable releases containing the referenced ACPI PCI fix
  • Review local kernel configurations for ACPI and PCI hot-add support and disable where unnecessary

The record

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.

Affected packages

Ecosystem Package Introduced Fixed