CVE-2026-63950: Linux Kernel Privilege Escalation Flaw

CVE-2026-63950 Overview

CVE-2026-63950 is a Linux kernel memory management vulnerability in the reverse mapping (rmap) subsystem. The flaw resides in try_to_unmap_one() within mm/rmap.c, where the nr_pages variable fails to reinitialize at the start of each loop iteration. A stale nr_pages value from a prior folio_unmap_pte_batch() call can persist into subsequent iterations that skip the batching path. This causes folio refcount and mapcount corruption when processing device-exclusive page table entries alongside lazyfree anonymous folios. The condition triggers kernel crashes reachable from local unprivileged code paths involving madvise(MADV_FREE) on droppable anonymous mappings.

Critical Impact
Local attackers can corrupt kernel folio reference counters, producing kernel panics and potential memory safety violations across affected Linux kernel builds.

Affected Products

Linux kernel builds containing lazyfree folio batching in the rmap subsystem
Kernels supporting device-exclusive PTEs via HMM (HMM_DMIRROR_EXCLUSIVE)
Systems permitting MAP_DROPPABLE anonymous mappings combined with MADV_FREE

Discovery Timeline

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

Technical Details for CVE-2026-63950

Vulnerability Analysis

The defect is a kernel state-tracking bug [Uninitialized Memory Use] inside the page reverse-mapping walker. try_to_unmap_one() iterates over page table entries mapping a folio using a page-vma walk. On iterations that map a batchable lazyfree PTE range, the code sets nr_pages via folio_unmap_pte_batch() and clears multiple PTEs in one step. On iterations that do not invoke the batching helper, nr_pages retains its previous value instead of being reset to 1.

When the walker subsequently encounters a device-exclusive PTE, the stale batch count is applied to a single-page operation. Subsequent calls to folio_remove_rmap_ptes() decrement mapcount and refcount by the wrong quantity. The imbalance propagates through the memory reclaim path and eventually manifests as a kernel crash.

Root Cause

The root cause is missing initialization of the loop-local nr_pages counter at the top of each page_vma_mapped_walk iteration inside try_to_unmap_one(). The companion function folio_referenced_one() correctly resets nr_pages = 1 per iteration; try_to_unmap_one() did not. The fix, delivered in kernel commits 0fcc34d, 3f8968e, and f611db9, reinstates the per-iteration initialization.

Attack Vector

Triggering the flaw requires local execution and the ability to allocate a 64K large folio with MAP_ANONYMOUS | MAP_DROPPABLE, call madvise(MADV_FREE), and mark the last page device-exclusive through HMM_DMIRROR_EXCLUSIVE. Node reclaim is then initiated through sysfs. During reclaim, the rmap walker clears 15 of 16 PTEs of the lazyfree folio, retains nr_pages = 15, then reuses that count against the device-exclusive PTE. The reproducer path is local-only and does not permit remote exploitation.

No public exploit or proof-of-concept has been published. The reporter describes a userspace program that reliably produces a kernel trace.

Detection Methods for CVE-2026-63950

Indicators of Compromise

Kernel oops or panic messages referencing folio_remove_rmap_ptes, try_to_unmap_one, or folio_referenced_one in dmesg output.
BUG: Bad page state or refcount underflow warnings emitted during memory reclaim events.
Unexpected process termination correlated with MADV_FREE usage on anonymous mappings backed by HMM device-exclusive PTEs.

Detection Strategies

Inventory running kernel versions against the fix commits 0fcc34d0d8fe, 3f8968e9cbf9, and f611db9b771b published on git.kernel.org.
Correlate crash telemetry from kdump or pstore with reclaim-path stack frames touching rmap.c.
Audit workloads that combine HMM device drivers, MAP_DROPPABLE, and MADV_FREE, since these are the prerequisites for the trigger sequence.

Monitoring Recommendations

Ship dmesg, kmsg, and abrt/systemd-coredump records to a central log store and alert on rmap-related panic strings.
Track kernel package versions across the fleet and flag hosts still running vulnerable builds after vendor patches ship.
Monitor for repeated unexplained node reclaim-triggered crashes on GPU or accelerator hosts that use HMM.

How to Mitigate CVE-2026-63950

Immediate Actions Required

Apply the upstream fix from commits Kernel Git Commit 0fcc34d, Kernel Git Commit 3f8968e, and Kernel Git Commit f611db9 or a distribution kernel that includes them.
Prioritize systems that run HMM-based accelerator workloads or expose device-exclusive PTEs.
Restrict local shell access on multi-tenant hosts until patched kernels are deployed.

Patch Information

The fix reinitializes nr_pages to 1 at the start of each page_vma_mapped_walk iteration in try_to_unmap_one(), matching the pattern already used in folio_referenced_one(). Rebuild or update the kernel to a version containing the referenced stable commits, then reboot affected hosts. Distribution vendors typically backport the patch to supported long-term stable trees.

Workarounds

Disable or unload HMM device drivers (for example, hmm_dmirror) on hosts that do not require GPU or accelerator memory sharing.
Avoid workloads that combine MAP_DROPPABLE anonymous mappings with MADV_FREE where device-exclusive PTEs are in use.
Reduce reliance on aggressive node reclaim by tuning vm.zone_reclaim_mode and related sysfs knobs on affected NUMA hosts.

bash

# Verify the running kernel includes the fix commit
uname -r
git -C /usr/src/linux log --oneline | grep -E '0fcc34d|3f8968e|f611db9'

# Temporarily block the vulnerable HMM debug driver where not required
echo 'blacklist hmm_dmirror' | sudo tee /etc/modprobe.d/blacklist-hmm.conf
sudo depmod -a