{"id":"CVE-2026-63950","state":"PUBLISHED","title":"mm/rmap: initialize nr_pages to 1 at loop start in try_to_unmap_one","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.","publishedAt":"2026-07-19T14:55:43.404Z","updatedAt":"2026-08-05T12:37:35.244Z","severity":{"score":7.8,"label":"High","version":"3.1","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","source":"Linux"},"assigner":"Linux","products":["Linux Linux"],"affected":[{"vendor":"Linux","product":"Linux","defaultStatus":"unaffected","versions":[{"version":"354dffd29575cdf13154e8fb787322354aa9efc4","status":"affected","lessThan":"0fcc34d0d8fefca4fea349e45c10e3a3d90350eb","versionType":"git"},{"version":"354dffd29575cdf13154e8fb787322354aa9efc4","status":"affected","lessThan":"f611db9b771b2b6775357555d2517af044fca4f0","versionType":"git"},{"version":"354dffd29575cdf13154e8fb787322354aa9efc4","status":"affected","lessThan":"3f8968e9cbf95d5d87d32218906cab0b9b9eddbe","versionType":"git"}],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["mm/rmap.c"]},{"vendor":"Linux","product":"Linux","defaultStatus":"affected","versions":[{"version":"6.15","status":"affected"},{"version":"0","status":"unaffected","lessThan":"6.15","versionType":"semver"},{"version":"6.18.35","status":"unaffected","lessThanOrEqual":"6.18.*","versionType":"semver"},{"version":"7.0.12","status":"unaffected","lessThanOrEqual":"7.0.*","versionType":"semver"},{"version":"7.1","status":"unaffected","lessThanOrEqual":"*","versionType":"original_commit_for_fix"}],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["mm/rmap.c"]}],"references":["https://git.kernel.org/stable/c/0fcc34d0d8fefca4fea349e45c10e3a3d90350eb","https://git.kernel.org/stable/c/f611db9b771b2b6775357555d2517af044fca4f0","https://git.kernel.org/stable/c/3f8968e9cbf95d5d87d32218906cab0b9b9eddbe"],"weaknesses":[],"ingestedAt":"2026-10-29T20:12:41.951Z","source":{"repository":"CVEProject/cvelistV5","path":"cves/2026/63xxx/CVE-2026-63950.json","commit":"556c9d3a8cd17e218bb8e452ba7cd619a384ff47"},"raw":{"dataType":"CVE_RECORD","dataVersion":"5.2","cveMetadata":{"cveId":"CVE-2026-63950","state":"PUBLISHED","datePublished":"2026-07-19T14:55:43.404Z","dateUpdated":"2026-08-05T12:37:35.244Z","assignerShortName":"Linux","assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","dateReserved":"2026-07-19T07:54:57.023Z"},"containers":{"cna":{"title":"mm/rmap: initialize nr_pages to 1 at loop start in try_to_unmap_one","descriptions":[{"lang":"en","value":"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."}],"affected":[{"vendor":"Linux","product":"Linux","defaultStatus":"unaffected","versions":[{"version":"354dffd29575cdf13154e8fb787322354aa9efc4","status":"affected","lessThan":"0fcc34d0d8fefca4fea349e45c10e3a3d90350eb","versionType":"git"},{"version":"354dffd29575cdf13154e8fb787322354aa9efc4","status":"affected","lessThan":"f611db9b771b2b6775357555d2517af044fca4f0","versionType":"git"},{"version":"354dffd29575cdf13154e8fb787322354aa9efc4","status":"affected","lessThan":"3f8968e9cbf95d5d87d32218906cab0b9b9eddbe","versionType":"git"}],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["mm/rmap.c"]},{"vendor":"Linux","product":"Linux","defaultStatus":"affected","versions":[{"version":"6.15","status":"affected"},{"version":"0","status":"unaffected","lessThan":"6.15","versionType":"semver"},{"version":"6.18.35","status":"unaffected","lessThanOrEqual":"6.18.*","versionType":"semver"},{"version":"7.0.12","status":"unaffected","lessThanOrEqual":"7.0.*","versionType":"semver"},{"version":"7.1","status":"unaffected","lessThanOrEqual":"*","versionType":"original_commit_for_fix"}],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["mm/rmap.c"]}],"references":[{"url":"https://git.kernel.org/stable/c/0fcc34d0d8fefca4fea349e45c10e3a3d90350eb"},{"url":"https://git.kernel.org/stable/c/f611db9b771b2b6775357555d2517af044fca4f0"},{"url":"https://git.kernel.org/stable/c/3f8968e9cbf95d5d87d32218906cab0b9b9eddbe"}],"metrics":[{"cvssV3_1":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","baseScore":7.8,"baseSeverity":"HIGH"},"scenarios":[{"lang":"en","value":"AV:L - Exploitation requires local syscalls (mmap with MAP_DROPPABLE, madvise MADV_FREE/MADV_PAGEOUT, and a device-exclusive ioctl such as HMM_DMIRROR_EXCLUSIVE or GPU SVM) that drive kernel memory reclaim into try_to_unmap_one(); there is no network-facing entry point.\nAC:L - The reporter provides a deterministic userspace reproducer and the attacker fully controls the memory layout (64K lazyfree large folio with one device-exclusive PTE) and reclaim triggering; no race or layout condition outside attacker control is required beyond having DEVICE_PRIVATE/THP enabled.\nPR:L - A normal unprivileged local process can perform the required mmap/madvise sequence and trigger reclaim via MADV_PAGEOUT or memory pressure; marking a page device-exclusive only needs access to a GPU render node or hmm_dmirror test device, which is routinely granted to unprivileged users on GPU-equipped systems.\nUI:N - No victim interaction is required; the attacker runs the exploit sequence in their own process to corrupt folio refcount/mapcount during reclaim.\nS:U - Impact is confined to kernel memory management within the same security authority; this is standard kernel memory corruption/privilege-escalation territory, not a VM escape or cross-authority boundary bypass.\nC:H - Stale nr_pages causes folio_remove_rmap_ptes() and folio_put_refs() to operate on the wrong page count, corrupting mapcount and refcount; the author confirms refcount/mapcount corruption and this class of bug can yield use-after-free with arbitrary read primitives.\nI:H - Incorrect multi-page rmap removal and reference dropping on a single device-exclusive PTE is exploitable memory corruption that can lead to use-after-free and arbitrary kernel write/control-flow hijack, not merely a bounded modification.\nA:H - The fix commit and reporter explicitly state the userspace-visible effect is kernel crashes (oops/panic) from refcount/mapcount corruption, observed at folio_remove_rmap_ptes in try_to_unmap_one."}]}],"providerMetadata":{"shortName":"Linux","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","dateUpdated":"2026-08-05T12:37:35.244Z"},"cpeApplicability":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.15","versionEndExcluding":"6.18.35"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.15","versionEndExcluding":"7.0.12"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.15","versionEndExcluding":"7.1"}]}]}],"x_generator":{"engine":"bippy-1.2.0"}}}}}