Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGain local low-privileged access
-
DeliveryTrigger ACPI platform device enumeration/teardown
-
ExploitRace freeing of primary device reference
-
ExecutionReach use-after-free in kernel
-
ImpactCorrupt kernel memory for privilege escalation
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Memory lifecycle management
MITRE ATT&CK
2 techniques across 2 tactics: Execution, Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires local access with the ability to drive ACPI platform device creation/teardown (the code paths acpi_platform_fill_resource() and acpi_create_platform_device()), such as device probe/remove or hotplug operations, and to win a race where the acpi_get_first_physical_node()-returned device is freed concurrently. Limiting factors: no remote vector (AV:L), low privileges are still needed (PR:L), the flaw is a race on an object lifetime that is hard to trigger deterministically, and only kernels built with the ACPI platform subsystem (standard on ACPI-based x86 systems) prior to the fix commits are affected - patched stable kernels are not. |
| Impact | This is a local-only Linux kernel use-after-free (CWE-416) with a vendor-assigned CVSS of 7.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). The signals are consistent in pointing to LOW real-world urgency despite the high-ish base score: EPSS is only 0.14% (3rd percentile), there is no CISA KEV listing (confirmed actively exploited = NO), and no public exploit code is referenced in any source (git.kernel.org, NVD, EUVD, VulDB). The commit description itself frames this as a defensive/correctness fix - 'in theory the device returned by it may be freed at any time' - i.e. a theoretical UAF hardened proactively rather than an observed exploitable primitive. Conflict to flag explicitly: the vendor vector uses AC:L, but the flaw is a lifetime/race issue on an ACPI primary device reference that is realistically hard to win deterministically, so AC:L likely overstates ease of triggering - treat the 7.8 as a conservative upper bound. Bottom line: this is a legitimate memory-safety fix worth patching in normal kernel update cadence, not an emergency; it is a high-CVSS-but-low-real-risk item given local access requirements, no exploitation evidence, and low EPSS. |
| Exploit ScenarioDerived | A local, low-privileged attacker on a Linux host triggers ACPI platform-device creation/teardown (e.g., via device hotplug or driver (un)bind paths) to race the freeing of the primary ACPI device reference used in acpi_platform_fill_resource()/acpi_create_platform_device(), reaching freed memory. Successful exploitation of the resulting use-after-free could corrupt kernel memory and potentially escalate privileges. No public proof-of-concept or exploit code is identified at time of analysis, and the window is a narrow race. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 21, 2026
A use-after-free (CWE-416) in the Linux kernel's ACPI platform device code lets a local attacker with low privileges crash or potentially corrupt kernel memory by racing device creation/teardown against the lifetime of the physical device node returned by acpi_get_first_physical_node(). Kernels from 4.6 onward that include the ACPI platform subsystem (standard on ACPI-based x86 systems) are affected only until the fix commits are applied; stable kernels patched to 7.2.6 or 7.3-rc1 are not vulnerable. No public exploit code has been identified and the flaw is not in CISA KEV, with EPSS at 0.14% (3rd percentile); successful abuse requires winning a race that is difficult to trigger deterministically, so real-world risk is concentrated on multi-tenant or locally shared hosts.
RemediationAI
Vendor-released patch: Linux 7.2.6 and Linux 7.3-rc1 (and later) contain the fix; apply the corresponding stable backport commits a9ba4dd2f18bf3f439d9ef0d8f375f90360ba1bd, c9d202d3b6c28e8c779cd2f2b10d2f7ab665ca71, 527a497fb2ef77a95170eefe2007e2c4c957bd2c or a75e5de593ef158feb17989bff7730c5a3d82503 for your kernel branch, or install the updated kernel package from your distribution once it ships the backport (track https://nvd.nist.gov/vuln/detail/CVE-2026-100072 and https://vuldb.com/vuln/410201). Because the trigger requires local code able to drive ACPI platform device creation and teardown, compensating controls are to keep untrusted users off ACPI-capable hosts (the flaw is in kernel code, not a service, so there is no endpoint or port to block), to avoid granting local shell or container access to workloads that can issue device hotplug or driver bind/unbind operations, and to constrain CAP_SYS_ADMIN and write access to /sys/bus/*/drivers/*/{bind,unbind} and ACPI hotplug interfaces to administrative accounts only. Restricting unprivileged user namespaces and module loading reduces the pool of local principals who could attempt the race, at the cost of breaking container tooling and legitimate module workflows; there is no effective way to disable the ACPI platform subsystem on ACPI-based hardware without losing device enumeration, so patching remains the primary mitigation. Reboot into the patched kernel after upgrade, since the fix cannot be applied at runtime.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The Linux ACPI platform subsystem translates ACPI namespace nodes into Linux platform_device objects so drivers can bind to firmware-described hardware. In acpi_platform_fill_resource() and acpi_create_platform_device(), the kernel previously called acpi_get_first_physical_node() to obtain the struct device backing an ACPI handle; that helper returns a borrowed pointer whose reference is not held by the caller, so in theory the device can be freed concurrently while the platform device setup code is still using it, producing a classic CWE-416 use-after-free. The same helper was also invoked repeatedly for the same ACPI handle, wasting work. The upstream resolution replaces these calls with acpi_bus_get_primary_device(), which acquires a proper reference to the primary physical device, and restructures acpi_create_platform_device() to resolve the device once at entry and drop the reference on every return path. The bug class affects object lifetime management rather than parsing, so exploitation is a race on allocation/free ordering rather than a single malformed input; our independent assessment rates it AV:L/AC:H because the timing window is narrow, while the vendor score of 7.8 assumes AC:L. Impact if won is high for confidentiality, integrity and availability (C:H/I:H/A:H) since kernel memory corruption in a privileged subsystem can lead to escalation or crash.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Local-only kernel flaw needs low privilege (PR:L); exploiting a theoretical object-lifetime race warrants AC:H, with full kernel memory impact giving C/I/A:H.
Primary rating from NVD.
CVSS VectorNVD
Lifecycle Timeline
3DescriptionNVD
In the Linux kernel, the following vulnerability has been resolved:
ACPI: platform: Use acpi_bus_get_primary_device()
The acpi_get_first_physical_node() usage in acpi_platform_fill_resource() and acpi_create_platform_device() is generally unsafe because in theory the device returned by it may be freed at any time [1].
It is also inefficient because acpi_get_first_physical_node() is called multiple times for the same argument which can be avoided.
Address these issues by using acpi_bus_get_primary_device() instead of acpi_get_first_physical_node() and adjusting the code to call it just once at the beginning of and acpi_create_platform_device() and drop the device reference acquired by it upon the return from that function.
Executive ViewAI
A high-severity use-after-free in the Linux kernel's ACPI platform-device handling can allow a local low-privileged user to crash an affected host or corrupt kernel memory, with the greatest business exposure on multi-tenant and locally shared systems. No public exploit identified at time of analysis, and the flaw is not in CISA KEV, but standard ACPI-based x86 kernels from 4.6 onward remain affected until fixed releases 7.2.6 or 7.3-rc1 are applied.
Apply vendor patch.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Use-after-free vulnerabilities occur when a program continues to access memory through a pointer after that memory has been deallocated.
Memory corruption occurs when a program writes data beyond the boundaries of allocated memory regions or accesses memory in unintended ways, violating the integrity of the process's address space.
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
EUVD-2026-87069
GHSA-g9pc-522f-qjj8
NVD
CVE.org
EPSS
VulDB
Exploit-DB