Linux Kernel EUVD-2026-86061

Requires the kernel to invoke acpi_ns_build_normalized_path() against an ACPI namespace node that has been freed or invalidated - reachable through ACPI namespace operations driven by firmware ACPI tables or namespace teardown, not through a straightforward unauthenticated userspace call. Exploitation is limited to local reach (AV:L), depends on hitting the freed-node window (a race/lifetime condition), and affects Linux kernels before 6.12.111, 6.18.53, and 7.2 on ACPI-enabled platforms. There is no remote or network path.

The input CVSS vector (CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H, score 7.7) rates this as a high-severity local flaw, but the signals conflict with the underlying defect. This is a use-after-free in the ACPICA namespace walker acpi_ns_build_normalized_path(), a deeply internal ACPI subsystem routine that is not directly driven by unprivileged userspace input; the fix simply adds a NULL/validity check on the node before dereferencing it. PR:N and AC:L are optimistic - reaching a freed/invalid namespace node realistically depends on ACPI table content or teardown/race conditions rather than a clean unauthenticated local API call, so the practical prerequisites are narrower than the vector implies. No EPSS score, no CISA KEV listing, and no public POC are provided, so there is no evidence of active exploitation or automatable weaponization. The declared C:H/A:H impact is questionable: a UAF here is overwhelmingly a crash/DoS (A:H) with at most incidental disclosure, not a reliable confidentiality breach, so I assess this as a real-but-lower-priority hardening fix rather than an urgent high-risk vulnerability. Note the input Tag 'Information Disclosure' is mislabeled - this is a CWE-416 memory-corruption issue (CWE is listed N/A upstream).

A local attacker (or a malicious/corrupted ACPI table processed at boot or via hotplug) drives the kernel to walk an ACPI namespace path where a node has already been freed or is otherwise invalid, causing acpi_ns_build_normalized_path() to dereference a stale pointer. The result is most likely a kernel crash (denial of service), with a theoretical chance of leaking adjacent freed memory. No public exploit code is identified at time of analysis.