CVE-2026-63950

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