CVE-2026-63950
Received Received - Intake

Memory Corruption in Linux Kernel mm/rmap

Publication date: 2026-07-19

Last updated on: 2026-07-19

Assigner: kernel.org

Description
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.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-07-19
Last Modified
2026-07-19
Generated
2026-07-20
AI Q&A
2026-07-19
EPSS Evaluated
N/A
NVD
CVE-2026-63950
EUVD
EUVD-2026-45723

Affected Vendors & Products

Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This vulnerability in the Linux kernel involves incorrect initialization of the nr_pages variable in the try_to_unmap_one function. Without proper initialization, nr_pages from a previous operation can be reused in subsequent iterations, leading to potential corruption of folio reference and map counts. This can cause kernel crashes due to refcount or mapcount corruption.

Detection Guidance

This vulnerability requires kernel-level detection due to its nature in memory management. Monitor kernel logs for crashes or trace outputs indicating refcount/mapcount corruption. Check for unusual folio_unmap_pte_batch or try_to_unmap_one errors in system logs. No direct network detection commands are applicable.

Impact Analysis

The vulnerability can cause the Linux kernel to crash, leading to system instability or denial of service. Users may experience unexpected system reboots or freezes if the kernel encounters the corruption during normal operations.

Compliance Impact

This vulnerability could lead to kernel crashes due to refcount and mapcount corruption, potentially causing system instability or denial of service. Such crashes may disrupt data processing or storage operations, which could impact compliance with GDPR (data integrity and availability) or HIPAA (system reliability for protected health information).

Mitigation Strategies

Apply the kernel patch resolving this issue immediately. Update to a patched Linux kernel version. Avoid using MAP_ANONYMOUS | MAP_DROPPABLE with madvise(MADV_FREE) on large folios until patched. Monitor system stability and kernel logs for signs of corruption.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-63950. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart