Look up another CVE · open CVE-2026-63950 in the interactive tracker
CVE-2026-63950
mm/rmap: initialize nr_pages to 1 at loop start in try_to_unmap_one
Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem mm. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-63950 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
mm/rmap.c
- What this is
- MEMORY MANAGEMENT - RMAP (REVERSE MAPPING)MAINTAINERS section matched on mm/rmap.c · linux-mm@kvack.org · Maintained
Show whether Debian builds this, per release
Not established. This site could not find the build rule for the affected file in the kernel trees Debian ships, so it has no answer about whether Debian compiles this code. Read that as unknown, never as absent.
- bookworm, trixie, forky, sid?
- ?
- not established - no Makefile entry for the affected file
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS
Signals
- Published
- 2026-07-19 (3 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.17%, higher than 6.3% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- mm
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.15 | 6.18.35 | 0fcc34d0d8fe |
| 6.15 | 7.0.12 | f611db9b771b |
| 6.15 | 7.1 | 3f8968e9cbf9 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- 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.
- AC:LAttack complexity, low
- 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.
- PR:LPrivileges required, low
- 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.
- UI:NUser interaction, none
- No victim interaction is required; the attacker runs the exploit sequence in their own process to corrupt folio refcount/mapcount during reclaim.
- S:UScope, unchanged
- 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.
- C:HConfidentiality impact, high
- 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.
- I:HIntegrity impact, high
- 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.
- A:HAvailability impact, high
- 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.