CVE-2026-64510

What it actually does

This is a Linux kernel use-after-free flaw in the ACPI NFIT/NVDIMM driver cleanup path. If acpi_nfit_init() fails after an NFIT descriptor is added to the global acpi_descs list, or if an NFIT descriptor is later allocated through the ACPI notification path without the proper shutdown cleanup action being registered, a freed acpi_desc object can remain reachable through that list. A subsequent ACPI Machine Check Exception can cause nfit_handle_mce() to iterate the stale pointer, resulting in kernel memory corruption. Because exploitation occurs in kernel context, a successful local attacker could potentially cause denial of service, read or corrupt sensitive kernel memory, or escalate privileges, although the published CVSS vector indicates local access, low privileges, and high attack complexity are required.

Why it matters to the business

Systems using affected Linux kernel versions with ACPI NFIT/NVDIMM support may be vulnerable to local privilege escalation or kernel crashes under specific hardware and error-handling conditions. The most likely operational impact is instability or unexpected reboot/panic on systems with persistent memory/NVDIMM-related ACPI NFIT functionality, while the worst-case impact is full host compromise by a local user or compromised process. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS at this time, and has no known public exploit maturity, so remediation should be prioritized for exposed multi-user Linux servers, virtualization hosts, high-value systems, and platforms using persistent memory rather than treated as an internet-scale emergency.

How an attack unfolds

An attacker first needs local code execution with low privileges on a Linux system running an affected kernel and using the vulnerable ACPI NFIT/NVDIMM code path. The attacker would then need to influence or wait for a failure path in NFIT initialization or driver removal/notification handling that leaves a freed acpi_desc object referenced in the global acpi_descs list. After that stale pointer exists, the attacker would need to trigger or coincide with a subsequent ACPI Machine Check Exception so that nfit_handle_mce() walks the corrupted list and dereferences freed memory. If the attacker can shape memory reuse reliably, the use-after-free may be turned into kernel memory corruption and potentially privilege escalation; otherwise, exploitation is more likely to result in a kernel panic or system crash. The required hardware/firmware state and MCE timing make exploitation high-complexity compared with common local kernel privilege-escalation bugs.

How to fix it

Upgrade to a Linux kernel version that includes the upstream ACPI NFIT cleanup fix. Because no product-specific fixed versions were provided, use the security advisories and kernel packages from the relevant Linux distribution or kernel vendor, and verify that the patch includes the changes to call acpi_nfit_shutdown() on acpi_nfit_init() failure, add the NFIT driver remove callback, add NULL checks in acpi_nfit_shutdown(), and clear nvdimm_bus during unregister. Where immediate patching is not possible, reduce exposure by disabling or unloading unused NFIT/NVDIMM/persistent-memory functionality where operationally safe, restricting local shell access, limiting untrusted workloads on affected hosts, and applying standard kernel hardening controls. Mitigations should be tested carefully because disabling ACPI NFIT or NVDIMM support can affect persistent memory devices and storage availability.

How to confirm the fix worked

Confirm the running kernel package is updated to a vendor release containing the ACPI NFIT fix, not merely that a patched package is installed. Validate with uname -a, distribution package metadata, and the vendor advisory or changelog for the active kernel. Check whether the vulnerable functionality is present by reviewing loaded modules and kernel configuration for ACPI NFIT/NVDIMM support, such as nfit, libnvdimm, CONFIG_ACPI_NFIT, and CONFIG_LIBNVDIMM. If the system uses persistent memory, perform a controlled reboot after patching and verify that NFIT/NVDIMM devices are still detected and functional. For custom kernels, confirm the source tree contains the corrected acpi_nfit_probe(), acpi_nfit_shutdown(), acpi_nfit_unregister(), and NFIT driver remove-path logic.

Typical attack path

1. Gain local execution on a Linux host running an affected kernel with ACPI NFIT/NVDIMM support present or reachable.
2. Identify whether NFIT/persistent-memory ACPI devices and the nfit driver are active, loaded, or can be exercised.
3. Trigger or wait for an acpi_nfit_init() failure, NFIT notification path, or driver removal sequence that leaves a freed acpi_desc object in the global acpi_descs list.
4. Cause, induce, or wait for a subsequent ACPI Machine Check Exception that invokes nfit_handle_mce().
5. Leverage the resulting use-after-free to crash the kernel or, with reliable heap control, attempt kernel memory corruption and privilege escalation.

How to detect it

Retrospective detection should focus on kernel telemetry rather than network indicators, because exploitation requires local access and occurs inside the kernel ACPI NFIT/NVDIMM path. Review dmesg, journald, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore artifacts, and EDR kernel-event telemetry for ACPI NFIT initialization failures followed by Machine Check Exceptions, kernel oopses, panics, slab/use-after-free reports, or faults involving nfit_handle_mce, acpi_nfit_init, acpi_nfit_probe, acpi_nfit_update_notify, acpi_nfit_shutdown, or acpi_nfit_unregister. Investigate any sequence where NFIT/NVDIMM driver removal, notification handling, or initialization errors precede an MCE and crash. Also review local user activity, sudo/su logs, container workload activity, and recent execution history around the time of any MCE or kernel panic, because a malicious attempt would require local execution. There are no known threat actors, ransomware campaigns, or public exploit artifacts associated with this issue at this time, so detection should emphasize anomalous local activity correlated with kernel fault evidence.

• nfit_handle_mce
• acpi_nfit_init
• acpi_nfit_probe
• acpi_nfit_update_notify
• acpi_nfit_shutdown
• acpi_nfit_unregister
• ACPI: NFIT
• NFIT
• NVDIMM
• libnvdimm
• Machine Check Exception
• mce:
• BUG: KASAN: use-after-free
• BUG: unable to handle kernel paging request
• general protection fault
• kernel NULL pointer dereference
• kernel panic
• Oops:
• Call Trace:
• RIP: 0010:nfit_handle_mce
• RIP: 0010:acpi_nfit_init
• RIP: 0010:acpi_nfit_shutdown
• /var/log/kern.log
• /var/log/messages
• /var/crash/
• /proc/config.gz
• CONFIG_ACPI_NFIT
• CONFIG_LIBNVDIMM

What your security team should do

• Prioritize patching Linux systems that allow local users, run untrusted workloads, host containers or virtual machines, or use persistent memory/NVDIMM hardware.
• Inventory systems with ACPI NFIT/NVDIMM support enabled by checking loaded nfit/libnvdimm modules, kernel configuration, and persistent-memory device presence.
• Apply vendor-supplied kernel updates and reboot into the patched kernel; confirm the old vulnerable kernel is no longer running.
• Where patching is delayed, restrict local access, reduce untrusted workload execution, and disable unused NFIT/NVDIMM functionality only after confirming there is no business dependency.
• Monitor kernel logs for ACPI NFIT initialization failures, NVDIMM bus registration/unregistration messages, Machine Check Exceptions, kernel oopses, and use-after-free reports.
• For high-value multi-user systems, review recent local account activity and kernel crash records even though there is currently no known public exploit or KEV listing.
• Ensure crash dump collection and kernel logging are enabled so any future suspected exploitation can be investigated.