CVE-2026-63950
Full vulnerability record from the local CVENow database.
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.
View original CVE JSON
{
"id": "CVE-2026-63950",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2026-07-19T16:17:13.730",
"lastModified": "2026-10-30T14:27:36.503",
"vulnStatus": "Analyzed",
"cveTags": [],
"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": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"affectedData": [
{
"vendor": "Linux",
"product": "Linux",
"defaultStatus": "unaffected",
"programFiles": [
"mm/rmap.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"versions": [
{
"version": "354dffd29575cdf13154e8fb787322354aa9efc4",
"lessThan": "0fcc34d0d8fefca4fea349e45c10e3a3d90350eb",
"versionType": "git",
"status": "affected"
},
{
"version": "354dffd29575cdf13154e8fb787322354aa9efc4",
"lessThan": "f611db9b771b2b6775357555d2517af044fca4f0",
"versionType": "git",
"status": "affected"
},
{
"version": "354dffd29575cdf13154e8fb787322354aa9efc4",
"lessThan": "3f8968e9cbf95d5d87d32218906cab0b9b9eddbe",
"versionType": "git",
"status": "affected"
}
]
},
{
"vendor": "Linux",
"product": "Linux",
"defaultStatus": "affected",
"programFiles": [
"mm/rmap.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"versions": [
{
"version": "6.15",
"status": "affected"
},
{
"version": "0",
"lessThan": "6.15",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "6.18.35",
"lessThanOrEqual": "6.18.*",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "7.0.12",
"lessThanOrEqual": "7.0.*",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "7.1",
"lessThanOrEqual": "*",
"versionType": "original_commit_for_fix",
"status": "unaffected"
}
]
}
]
}
],
"metrics": {
"cvssMetricV31": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary",
"cvssData": {
"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",
"attackVector": "LOCAL",
"attackComplexity": "LOW",
"privilegesRequired": "LOW",
"userInteraction": "NONE",
"scope": "UNCHANGED",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"availabilityImpact": "HIGH"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9
}
]
},
"weaknesses": [
{
"source": "[email protected]",
"type": "Primary",
"description": [
{
"lang": "en",
"value": "CWE-476"
}
]
}
],
"configurations": [
{
"nodes": [
{
"operator": "OR",
"negate": false,
"cpeMatch": [
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "6.15",
"versionEndExcluding": "6.18.35",
"matchCriteriaId": "264F6745-E680-4AA9-A01E-4F9E3E10F604"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "6.19",
"versionEndExcluding": "7.0.12",
"matchCriteriaId": "9161A938-0FA8-44BC-95FE-C5A271601AB3"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:7.1:rc1:*:*:*:*:*:*",
"matchCriteriaId": "B1EF7059-E670-45F4-B422-54C40FA86390"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:7.1:rc2:*:*:*:*:*:*",
"matchCriteriaId": "0D38F0BF-A728-4133-A358-D44A2F7EE6D6"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:7.1:rc3:*:*:*:*:*:*",
"matchCriteriaId": "EC732D08-5F7B-46D9-B154-E60C7F4F0A97"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:7.1:rc4:*:*:*:*:*:*",
"matchCriteriaId": "E5910A9D-F60A-409A-B486-FE66BFEBA9B9"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:7.1:rc5:*:*:*:*:*:*",
"matchCriteriaId": "81DFF19E-9CF8-49C6-8C36-1E4038622933"
}
]
}
]
}
],
"references": [
{
"url": "https://git.kernel.org/stable/c/0fcc34d0d8fefca4fea349e45c10e3a3d90350eb",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
]
},
{
"url": "https://git.kernel.org/stable/c/3f8968e9cbf95d5d87d32218906cab0b9b9eddbe",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
]
},
{
"url": "https://git.kernel.org/stable/c/f611db9b771b2b6775357555d2517af044fca4f0",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
]
}
]
}