{"id":"CVE-2026-63950","url":"https://www.cyber-defence.io/tools/cve/CVE-2026-63950","generatedAt":"2026-10-28T00:28:28.938Z","title":"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.","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/rmap: initialize nr_pages to 1 at loop start in try_to_unmap_one\n\nInitialize nr_pages to 1 at the start of each loop iteration, like\nfolio_referenced_one() does.\n\nWithout this, nr_pages computed by a previous folio_unmap_pte_batch() call\ncan be reused on a later iteration that does not run\nfolio_unmap_pte_batch() again.\n\nmmap a 64K large folio with MAP_ANONYMOUS | MAP_DROPPABLE, then call\nmadvise(MADV_FREE), then make the last page device-exclusive via\nHMM_DMIRROR_EXCLUSIVE.\n\nTrigger node reclaim through sysfs.  Now, in try_to_unmap_one(), we will\nfirst clear the first 15 out of 16 entries mapping the lazyfree folio. \nThis will set nr_pages to 15.  In the next pvmw walk, this nr_pages gets\nreused on a device-exclusive pte, thus potentially corrupting folio\nrefcount/mapcount.\n\nAt the moment, I have a userspace program which can make the kernel spit\nout a trace, but the blow up is in folio_referenced_one(), because there\nare existing bugs in the interaction between device-private and rmap\n(which too I am investigating).  I did a one liner kernel change to avoid\ngoing into folio_referenced_one(), and the kernel blows up at\nfolio_remove_rmap_ptes in try_to_unmap_one which is what I wanted.\n\nNote that the bug is there not since file folio batching but lazyfree\nfolio batching, since device-exclusive only works for anonymous folios.\n\nUserspace visible effect is simply kernel crashing somewhere due to\nrefcount/mapcount corruption.","published":"2026-07-19T16:17:14.000Z","lastModified":"2026-07-27T17:44:24.000Z","status":"Awaiting Analysis","sourceIdentifier":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","cvss":{"version":"3.1","score":7.8,"severity":"HIGH","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"cwe":[],"affected":[],"epss":{"score":0.00173,"percentile":0.06725,"date":"2026-10-26","history":[]},"kev":{"listed":false},"exploits":{"count":0,"verified":false,"firstPublished":null,"source":"Exploit-DB (https://gitlab.com/exploit-database/exploitdb)","entries":[]},"verdict":{"level":"high","text":"High impact if exploited, but EPSS currently rates exploitation as unlikely (0.17%). Schedule it in the normal patch cycle and watch for a rise in EPSS or a public exploit."},"changes":[],"references":[{"url":"https://git.kernel.org/stable/c/0fcc34d0d8fefca4fea349e45c10e3a3d90350eb","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/3f8968e9cbf95d5d87d32218906cab0b9b9eddbe","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/f611db9b771b2b6775357555d2517af044fca4f0","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"}],"sources":{"nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-63950","epss":"https://www.first.org/epss/","kev":"https://www.cisa.gov/known-exploited-vulnerabilities-catalog","exploitdb":"https://www.exploit-db.com/"},"licence":"CC BY 4.0 — link back to the CVE Explorer if you publish the results; upstream data remains subject to its own terms."}