CVE-2026-64131: Linux Kernel Memory Management Vulnerability

CVE-2026-64131 Overview

CVE-2026-64131 is a Linux kernel vulnerability in the memory management subsystem (mm/memory). The flaw triggers a spurious kernel warning when unmapping device-private or device-exclusive pages backed by private file-backed mappings. The unmap path uses vma_is_anonymous() to check an invariant that should be verified with folio_test_anon(). During process teardown, this mismatch produces a WARNING at unmap_page_range.cold+0x26/0x18a on systems using device migration features such as HMM and NVIDIA UVM.

Critical Impact
The bug generates kernel warnings during memory teardown on systems using device-private memory, tainting the kernel and potentially disrupting workloads that rely on GPU or accelerator memory migration.

Affected Products

Linux kernel versions containing the device-private/exclusive migration path in mm/memory.c
Systems using HMM (Heterogeneous Memory Management) test modules
Systems running NVIDIA UVM (nvidia_uvm) or other drivers using device-private memory

Discovery Timeline

2026-07-19 - CVE-2026-64131 published to NVD
2026-07-19 - Last updated in NVD database

Technical Details for CVE-2026-64131

Vulnerability Analysis

The issue stems from an incorrect assumption in the Linux kernel's memory unmap path. Device private and exclusive entries are only supported for anonymous folios. The kernel enforces this in __migrate_device_pages() and make_device_exclusive() using folio_test_anon(). However, the unmap path in unmap_page_range() verifies the same invariant using vma_is_anonymous().

These two checks are not equivalent. While anonymous virtual memory areas (VMAs) contain only folios where folio_test_anon() is true, the reverse does not hold. A folio can satisfy folio_test_anon() while residing in a non-anonymous VMA, such as a private file-backed mapping created via mmap(MAP_PRIVATE) on a file.

When a device migrates such a folio to device-private memory and the process later tears down, the unmap path hits the mismatched assertion and emits a WARNING at mm/memory.c:1754. The warning taints the kernel with the W flag, which impacts diagnostic reliability for downstream issues.

Root Cause

The root cause is inconsistent invariant checking between the migration entry creation paths and the unmap path. The creation paths use folio-level state (folio_test_anon()), whereas the unmap teardown logic uses VMA-level state (vma_is_anonymous()). Private file-backed mappings can legitimately hold anonymous folios after copy-on-write, breaking the VMA-level assumption.

Attack Vector

The issue is triggered during normal process teardown on systems with device drivers that migrate pages to device-private memory. Reproduction requires a driver capable of establishing device-private entries, such as test_hmm or nvidia_uvm, combined with a private file-backed mapping. This is a kernel correctness bug rather than a directly exploitable memory safety flaw, though warnings during teardown can mask or complicate diagnosis of other kernel faults.

The vulnerability manifests inside unmap_page_range() when called from unmap_vmas() during munmap() or process exit. See the kernel commits referenced below for the exact code paths and patch content.

Detection Methods for CVE-2026-64131

Indicators of Compromise

Kernel log entries containing WARNING: mm/memory.c with call trace referencing unmap_page_range.cold
Call traces including unmap_vmas, unmap_region, vms_complete_munmap_vmas, and __x64_sys_munmap
Kernel taint flag W appearing after workloads using test_hmm, nvidia_uvm, or other device-private memory drivers

Detection Strategies

Monitor dmesg and /var/log/kern.log for mm/memory.c warnings correlated with device driver modules loaded
Track kernel taint state on hosts running GPU compute workloads to identify affected systems
Correlate munmap syscall failures or anomalies with processes using HMM or CUDA UVM

Monitoring Recommendations

Ingest kernel logs into a centralized logging platform and alert on WARNING messages from mm/memory.c
Baseline kernel taint status across the fleet and flag unexpected transitions to tainted state
Track kernel version and patch level on GPU-equipped hosts to prioritize remediation

How to Mitigate CVE-2026-64131

Immediate Actions Required

Identify Linux hosts running device-private memory drivers such as nvidia_uvm or test_hmm
Apply the upstream kernel patch replacing the vma_is_anonymous() check with the correct folio_test_anon() check in the unmap path
Update to a stable kernel release containing the fix from the kernel.org stable tree

Patch Information

The fix is available in the following mainline and stable commits on kernel.org:

Workarounds

Avoid using MAP_PRIVATE file-backed mappings in workloads that also migrate memory to device-private storage
Unload device drivers that create device-private entries (for example test_hmm) when they are not required
Restrict use of HMM-enabled workloads to hosts running patched kernel versions