CVE Catalog

CVE-2026-63950

HighCVSS 7.8
Published: Updated: Translated: NVD NIST

Exploitation Probability (EPSS)

Low risk
0.16%

6th percentile - higher than 6% of all known CVEs

Summary

In the Linux kernel, a vulnerability in try_to_unmap_one in mm/rmap fails to initialize nr_pages at the start of each loop iteration, allowing reuse of a stale value from a previous folio_unmap_pte_batch() call. This can corrupt folio refcount/mapcount when combining MAP_DROPPABLE, MADV_FREE, and HMM_DMIRROR_EXCLUSIVE, leading to a kernel crash.

Risk Assessment

The risk is potential corruption of kernel memory structures, causing system crashes due to refcount/mapcount corruption. An attacker with local access could exploit this to destabilize the system.

Recommendation

Immediately update the Linux kernel to a version that includes the fix initializing nr_pages to 1 at the start of each loop iteration in try_to_unmap_one. Monitor official security advisories from your Linux distribution.

Other vulnerabilities in Linux kernel

See all
Original NVD description (English source)

In the Linux kernel, the following vulnerability has been resolved: mm/rmap: initialize nr_pages to 1 at loop start in try_to_unmap_one Initialize nr_pages to 1 at the start of each loop iteration, like folio_referenced_one() does. Without this, nr_pages computed by a previous folio_unmap_pte_batch() call can be reused on a later iteration that does not run folio_unmap_pte_batch() again. mmap a 64K large folio with MAP_ANONYMOUS | MAP_DROPPABLE, then call madvise(MADV_FREE), then make the last page device-exclusive via HMM_DMIRROR_EXCLUSIVE. Trigger node reclaim through sysfs. Now, in try_to_unmap_one(), we will first clear the first 15 out of 16 entries mapping the lazyfree folio. This will set nr_pages to 15. In the next pvmw walk, this nr_pages gets reused on a device-exclusive pte, thus potentially corrupting folio refcount/mapcount. At the moment, I have a userspace program which can make the kernel spit out a trace, but the blow up is in folio_referenced_one(), because there are existing bugs in the interaction between device-private and rmap (which too I am investigating). I did a one liner kernel change to avoid going into folio_referenced_one(), and the kernel blows up at folio_remove_rmap_ptes in try_to_unmap_one which is what I wanted. Note that the bug is there not since file folio batching but lazyfree folio batching, since device-exclusive only works for anonymous folios. Userspace visible effect is simply kernel crashing somewhere due to refcount/mapcount corruption.

Vulnerability data from NVD (NIST) · CISA KEV · EPSS