Look up another CVE · open CVE-2026-64181 in the interactive tracker
CVE-2026-64181
mm: fix __vm_normal_page() to handle missing support for pmd_special()/pud_special()
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-64181 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
On x86 32-bit with THP enabled, zap_huge_pmd() is seen to generate a "WARNING: mm/memory.c:735 at __vm_normal_page+0x6a/0x7d", from the VM_WARN_ON_ONCE(is_zero_pfn(pfn) || is_huge_zero_pfn(pfn)); followed by "BUG: Bad rss-counter state"s, then later "BUG: Bad page state"s when reclaim gets to call shrink_huge_zero_folio_scan(). It's as if the _PAGE_SPECIAL bit never got set in the huge_zero pmd: and indeed, whereas pte_special() and pte_mkspecial() are subject to a dedicated CONFIG_ARCH_HAS_PTE_SPECIAL, pmd_special() and pmd_mkspecial() are subject to CONFIG_ARCH_SUPPORTS_PMD_PFNMAP, which is never enabled on any 32-bit architecture. While the problem was exposed through commit d80a9cb1a64a ("mm/huge_memory: add and use normal_or_softleaf_folio_pmd()"), it was an oversight in commit af38538801c6 ("mm/memory: factor out common code from vm_normal_page_*()") and would result in other problems: * huge zero folio accounted in smaps, pagemap (PAGE_IS_FILE) and numamaps as file-backed THP * folio_walk_start() returning the folio even without FW_ZEROPAGE set. Callers seem to tolerate that, though. ... and triggering the VM_WARN_ON_ONE(), although never reported so far. To fix it, teach vm_normal_page_pmd()/vm_normal_page_pud() to consider whether pmd_special/pud_special is actually implemented.
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/memory.c
- What this is
- MEMORY MANAGEMENT - COREMAINTAINERS section matched on mm/memory.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.18 | 6.18.34 | 62153767e8fc |
| 6.18 | 7.0.11 | 9052ea2ee223 |
| 6.18 | 7.1 | c0c6ccd9828c |
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
- The bug is reached only through local memory-management syscalls (mmap, madvise, munmap, process teardown) that walk page tables and call zap_huge_pmd() → vm_normal_page_pmd() → __vm_normal_page(); there is no network, adjacent, or physical attack path.
- AC:LAttack complexity, low
- On affected 32-bit THP configurations an unprivileged attacker can deterministically create a huge zero PMD (mmap + MADV_HUGEPAGE + read fault) and trigger the bug (munmap or MADV_DONTNEED) without races or conditions outside their control.
- PR:LPrivileges required, low
- Exploitation requires only an unprivileged local user manipulating their own address space via standard syscalls; no root, capabilities, or authentication is needed.
- UI:NUser interaction, none
- No victim interaction is required; the attacker fully controls the memory mappings and the syscalls that trigger page-table zapping.
- S:UScope, unchanged
- Impact is confined to kernel memory-management corruption and accounting within the kernel security boundary; this is not a VM escape, IOMMU bypass, or cross-authority sandbox escape.
- C:HConfidentiality impact, high
- Misclassifying the shared huge zero folio as a normal page corrupts global rmap/mapcount state on a system-wide singleton folio, triggers VM_WARN/BUG checks, and misreports mappings in /proc/pagemap and smaps—memory corruption with plausible information-disclosure leverage.
- I:HIntegrity impact, high
- Incorrect rmap removal and RSS accounting on the global huge_zero_folio corrupts kernel memory metadata system-wide; callers such as KSM (vm_normal_page_pmd) may treat the zero folio as a normal anonymous folio, enabling cross-mapping integrity corruption beyond the attacker's VMA.
- A:HAvailability impact, high
- The bug triggers VM_WARN_ON_ONCE, "BUG: Bad rss-counter state" on mm teardown, and "BUG: Bad page state" during shrink_huge_zero_folio_scan() reclaim, any of which can crash or destabilize the kernel on affected systems.