CVE-2026-63950

/// Technical 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 t

/// Remediation

Check the references section for vendor advisories, patches, and mitigation guidance. If immediate patching is not possible, review the CVSS vector to understand the attack surface and apply compensating controls such as network segmentation or access restrictions.

/// References