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… (CVE-2026-63950)
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.
AI Analysis
Technical Summary
The vulnerability in the Linux kernel occurs because the variable nr_pages is not reinitialized to 1 at the start of each loop iteration in the try_to_unmap_one function. This allows nr_pages computed in a previous folio_unmap_pte_batch call to be reused improperly in subsequent iterations that do not call folio_unmap_pte_batch again. This flaw manifests when mmap is used to allocate a 64K large folio with MAP_ANONYMOUS and MAP_DROPPABLE flags, followed by madvise(MADV_FREE) and setting the last page to device-exclusive via HMM_DMIRROR_EXCLUSIVE. Triggering node reclaim via sysfs leads to partial clearing of folio mappings and reuse of stale nr_pages values, causing corruption of folio reference and map counts. The visible effect is kernel crashes due to this corruption. The issue is related to lazyfree folio batching and device-exclusive anonymous folios. A fix involves initializing nr_pages to 1 at each loop start, preventing reuse of stale values.
Potential Impact
The vulnerability can cause kernel crashes due to corruption of folio reference and map counts. This impacts system stability and reliability but does not have confirmed exploitation in the wild. The corruption arises from improper memory management in the kernel's handling of anonymous folios with specific memory advice and device-exclusive states.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until an official fix is available, users should monitor vendor communications for updates. No specific workaround or temporary mitigation is described in the available data.
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… (CVE-2026-63950)
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.
CVSS v3.1
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability in the Linux kernel occurs because the variable nr_pages is not reinitialized to 1 at the start of each loop iteration in the try_to_unmap_one function. This allows nr_pages computed in a previous folio_unmap_pte_batch call to be reused improperly in subsequent iterations that do not call folio_unmap_pte_batch again. This flaw manifests when mmap is used to allocate a 64K large folio with MAP_ANONYMOUS and MAP_DROPPABLE flags, followed by madvise(MADV_FREE) and setting the last page to device-exclusive via HMM_DMIRROR_EXCLUSIVE. Triggering node reclaim via sysfs leads to partial clearing of folio mappings and reuse of stale nr_pages values, causing corruption of folio reference and map counts. The visible effect is kernel crashes due to this corruption. The issue is related to lazyfree folio batching and device-exclusive anonymous folios. A fix involves initializing nr_pages to 1 at each loop start, preventing reuse of stale values.
Potential Impact
The vulnerability can cause kernel crashes due to corruption of folio reference and map counts. This impacts system stability and reliability but does not have confirmed exploitation in the wild. The corruption arises from improper memory management in the kernel's handling of anonymous folios with specific memory advice and device-exclusive states.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until an official fix is available, users should monitor vendor communications for updates. No specific workaround or temporary mitigation is described in the available data.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-9fqf-4mvh-6fx9
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-63950"]
- Ecosystems
- []
- Database Specific Severity
- null
- Cvss Version
- null
Threat ID: 6a5d27aa2a4a8d598912ebc5
Added to database: 07/19/2026, 19:38:18 UTC
Last enriched: 07/19/2026, 20:05:33 UTC
Last updated: 07/20/2026, 21:51:49 UTC
Views: 13
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.