CVE-2026-64511

What it actually does

This Linux kernel flaw is a NULL pointer dereference in the ACPI NFIT subsystem. The kernel installs an ACPI notify handler for an NFIT device before confirming that the NFIT table exists and before initializing the associated driver data structure. If an NFIT uncorrectable memory error notification is delivered in that window, the notification handler can dereference a NULL acpi_desc pointer. The most likely technical consequence is a kernel oops or panic, resulting in local denial of service. There is no public evidence of code execution, privilege escalation, or remote network exploitation, and the reported EPSS score is very low.

Why it matters to the business

Affected Linux systems that expose the vulnerable ACPI NFIT code path may crash if the vulnerable notification path is triggered, causing workload interruption, node loss, service failover, or maintenance events. Risk is highest for systems using persistent memory/NVDIMM or firmware paths involving ACPI NFIT. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has no known mature exploit, so remediation should be handled through normal kernel patch cycles unless the affected systems support NFIT/persistent memory or have a low tolerance for host crashes.

How an attack unfolds

An attacker would need a way to cause or influence an ACPI NFIT notification before the kernel has completed NFIT table validation and driver data initialization. In practical terms, this is most plausible through malicious or faulty platform firmware, a privileged local actor with control over low-level platform/ACPI behavior, or a lab environment capable of emulating or injecting ACPI events. Once the NFIT_NOTIFY_UC_MEMORY_ERROR notification reaches the vulnerable handler, the handler attempts to use an uninitialized driver data pointer and dereferences NULL. The system may log a kernel NULL pointer dereference referencing the ACPI NFIT notification path and may crash or panic depending on kernel configuration.

How to fix it

Apply a Linux kernel update that includes the ACPI NFIT fix adding a NULL acpi_desc check in acpi_nfit_uc_error_notify(). Because no product-specific fixed versions were provided, track the fix through the relevant Linux distribution, kernel vendor, or upstream stable kernel advisory stream. Prioritize systems using persistent memory, NVDIMM, ACPI NFIT, or hardware platforms known to emit NFIT notifications. Where immediate patching is not possible, reduce exposure by disabling unused persistent memory/NVDIMM features where supported, applying firmware updates from the hardware vendor, restricting privileged access that could influence ACPI or platform event injection, and ensuring crash recovery/failover mechanisms are functioning.

How to confirm the fix worked

Confirm the running kernel includes the upstream ACPI NFIT NULL-check fix or a vendor backport for this issue. Validate by checking the installed kernel package changelog or vendor advisory for the ACPI NFIT NULL pointer dereference fix, then reboot into the patched kernel and confirm the running kernel version with standard OS tooling. On systems where source or debug symbols are available, verify that acpi_nfit_uc_error_notify() checks for a NULL acpi_desc before dereferencing it. Also review hardware inventory to determine whether ACPI NFIT/persistent memory support is present; systems without NFIT exposure are less likely to be practically affected.

Typical attack path

1. Identify a Linux system running a kernel version that contains the vulnerable ACPI NFIT notify-handler ordering behavior.
2. Confirm the system exposes ACPI NFIT functionality, commonly associated with persistent memory/NVDIMM platforms or firmware tables.
3. Gain a way to influence low-level ACPI behavior, such as compromised firmware, privileged local access, virtualization/emulation control, or platform-management access capable of triggering relevant ACPI notifications.
4. Trigger an NFIT uncorrectable memory error notification while NFIT driver data has not been initialized because the NFIT table is absent or not accepted.
5. Cause the ACPI NFIT notification handler to dereference a NULL pointer, producing a kernel oops or panic and disrupting the host.

How to detect it

Look for evidence of prior kernel crashes or oops events involving the ACPI NFIT notification path. Useful sources include system journal logs, kernel ring buffer captures, persistent crash logs, kdump/vmcore artifacts, hypervisor console logs, out-of-band management event logs, and hardware firmware logs. Search for NULL pointer dereference messages where the call trace includes acpi_nfit_uc_error_notify, ACPI NFIT, or NFIT uncorrectable memory error handling. Also correlate unexpected reboots, kernel panics, watchdog resets, and persistent-memory hardware events. Because exploitation requires low-level ACPI notification triggering and there are no known public exploitation campaigns, detection should focus on crash forensics and anomalous platform/firmware event activity rather than network indicators.

• acpi_nfit_uc_error_notify
• ACPI: NFIT
• NFIT_NOTIFY_UC_MEMORY_ERROR
• UC_MEMORY_ERROR
• BUG: kernel NULL pointer dereference
• kernel NULL pointer dereference
• Unable to handle kernel NULL pointer dereference
• Kernel panic - not syncing
• RIP: acpi_nfit_uc_error_notify
• Call Trace: acpi_nfit_uc_error_notify

What your security team should do

• Inventory Linux systems that use persistent memory, NVDIMM, or ACPI NFIT-capable hardware and prioritize them for kernel updates.
• Patch affected kernels through the appropriate Linux distribution or hardware-appliance vendor once fixed packages are available.
• Review kernel logs for historical crashes involving acpi_nfit_uc_error_notify, ACPI NFIT, or NULL pointer dereferences to identify possible prior triggering.
• Ensure systems reboot into the patched kernel after update; merely installing a kernel package is not sufficient.
• Restrict privileged local access, firmware-management access, and virtualization controls that could be used to inject or emulate ACPI notifications.
• Update platform firmware where vendors provide ACPI/NFIT reliability fixes.
• For high-availability services, verify failover and crash-recovery procedures for hosts that cannot be patched immediately.