CVE-2026-64131

What it actually does

This is a Linux kernel memory-management flaw in the unmap path for device-private and device-exclusive page table entries used by HMM/device memory migration. The kernel checked whether the VMA was anonymous using vma_is_anonymous(), but the relevant condition is whether the folio itself is anonymous. A private file-backed mapping can contain an anonymous folio, allowing device-private migration while causing the unmap path to incorrectly hit a WARN condition during munmap or process teardown. The described effect is a spurious kernel warning; on systems configured to panic on warnings, this can become a local denial of service.

Why it matters to the business

The main operational risk is instability or outages on Linux systems that use device-private memory features, commonly associated with GPU, accelerator, or HMM-enabled workloads. Although public exploitation maturity is listed as none, EPSS is very low, and it is not in CISA KEV or known ransomware use, affected systems may still experience kernel warning storms, degraded reliability, or full crashes if kernel warnings are configured to trigger panics.

How an attack unfolds

An attacker would need local code execution or the ability to run a workload that can exercise device-private or device-exclusive memory migration. They create or use a private file-backed mapping whose folio is anonymous, trigger migration of that folio to device-private memory through an HMM-capable device or driver path, and then unmap the memory or terminate the process. During teardown, the kernel unmap path evaluates the wrong anonymity condition and emits a WARN from mm/memory.c. In most default configurations this is primarily log noise and kernel tainting; on hardened or debugging configurations where panic_on_warn is enabled, the same condition can crash the system and produce a local denial of service.

How to fix it

Apply the vendor-supplied Linux kernel update that includes the mm/memory fix for device-private and device-exclusive page unmapping. No exact fixed package versions were provided in the input, so track the fix through the operating-system or kernel vendor advisory for CVE-2026-64131. As interim risk reduction, avoid enabling panic_on_warn on production systems where untrusted users can run GPU/HMM workloads, restrict access to accelerator device nodes to trusted users and jobs, and limit exposure of HMM/device-private memory features in multi-user environments until the kernel is updated.

How to confirm the fix worked

Confirm the running kernel version contains the upstream or vendor backport for the mm/memory unmap fix. Review vendor changelogs for references to fixing spurious warnings when unmapping device-private or device-exclusive pages. After patching, run representative GPU/HMM/device-memory workloads that previously exercised device-private migration and verify that munmap or process teardown no longer produces WARN traces from unmap_page_range or mm/memory.c. Also verify that panic_on_warn is not unexpectedly enabled unless intentionally required.

Typical attack path

1. Obtain local execution on a Linux system with HMM/device-private or device-exclusive memory support exposed through GPU or accelerator drivers.
2. Create or interact with a private file-backed memory mapping that can contain anonymous folios.
3. Trigger device-private or device-exclusive page migration through the relevant driver/runtime path.
4. Unmap the affected range with munmap or allow process teardown to unmap it.
5. Cause the kernel to emit a WARN in the memory unmap path; if panic_on_warn is enabled, trigger a kernel panic and system outage.

How to detect it

To determine whether this condition has occurred, review kernel log sources such as dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash dumps, and centralized syslog/SIEM data. Look for WARN splats referencing mm/memory.c, unmap_page_range, munmap, unmap_vmas, or device-private/HMM-related call traces. Pay particular attention to systems running GPU or accelerator drivers and modules such as test_hmm, nvidia_uvm, or other HMM-enabled components. If panic_on_warn is enabled, also review kdump/vmcore records and reboot/crash telemetry for kernel panics immediately following these warning signatures. There are no reliable remote network indicators for this issue because exploitation requires local memory-management behavior rather than a network protocol artifact.

• WARNING: mm/memory.c:1754
• unmap_page_range.cold
• unmap_page_range
• unmap_vmas
• unmap_region
• vms_complete_munmap_vmas
• do_vmi_align_munmap
• do_vmi_munmap
• __vm_munmap
• __x64_sys_munmap
• dmirror_interval_invalidate
• test_hmm
• nvidia_uvm
• nvidia(O)
• Tainted: G W O
• panic_on_warn

What your security team should do

• Prioritize patching Linux systems that run GPU, accelerator, HMM, or device-private memory workloads, especially shared compute nodes and multi-user systems.
• Check whether panic_on_warn is enabled; if so, treat exposure as higher severity because a warning can become a host crash.
• Restrict access to GPU or accelerator device files and HMM-capable workloads to trusted users until kernel updates are deployed.
• Monitor kernel logs for WARN traces involving unmap_page_range, mm/memory.c, device-private pages, test_hmm, nvidia_uvm, or similar HMM-related modules.
• Because this is not KEV-listed, has no known ransomware association, and has very low EPSS, handle it through normal kernel maintenance unless the environment relies heavily on HMM/device-private memory or panic_on_warn is enabled.