In the Linux kernel, the following vulnerability has been resolved: mm: fix __vm_normal_page() to handle missing support for… (CVE-2026-64181)
In the Linux kernel, the following vulnerability has been resolved: mm: fix __vm_normal_page() to handle missing support for pmd_special()/pud_special() 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.
AI Analysis
Technical Summary
The Linux kernel vulnerability CVE-2026-64181 involves improper handling in the __vm_normal_page() function for architectures without support for pmd_special() and pud_special(), specifically affecting x86 32-bit with THP enabled. This led to kernel warnings and bugs such as "Bad rss-counter state" and "Bad page state" during memory reclaim operations. The root cause was that the _PAGE_SPECIAL bit was not set correctly for huge zero PMDs, due to missing CONFIG_ARCH_SUPPORTS_PMD_PFNMAP on 32-bit architectures. The problem was introduced by earlier commits that factored out common code but overlooked this architectural difference. The fix ensures vm_normal_page_pmd() and vm_normal_page_pud() check for actual implementation of pmd_special/pud_special, preventing these memory management inconsistencies.
Potential Impact
The vulnerability causes kernel warnings and bugs related to memory management on affected systems, including incorrect memory accounting and potential instability during memory reclaim. While no exploits in the wild are known, the issue can lead to system instability or crashes on 32-bit x86 systems with THP enabled due to improper page state handling.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Since this is a kernel-level issue, applying the official Linux kernel updates that address CVE-2026-64181 when available is recommended. Until then, consider disabling Transparent Huge Pages (THP) on affected 32-bit x86 systems as a temporary mitigation if feasible.
In the Linux kernel, the following vulnerability has been resolved: mm: fix __vm_normal_page() to handle missing support for… (CVE-2026-64181)
Description
In the Linux kernel, the following vulnerability has been resolved: mm: fix __vm_normal_page() to handle missing support for pmd_special()/pud_special() 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.
CVSS v3.1
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The Linux kernel vulnerability CVE-2026-64181 involves improper handling in the __vm_normal_page() function for architectures without support for pmd_special() and pud_special(), specifically affecting x86 32-bit with THP enabled. This led to kernel warnings and bugs such as "Bad rss-counter state" and "Bad page state" during memory reclaim operations. The root cause was that the _PAGE_SPECIAL bit was not set correctly for huge zero PMDs, due to missing CONFIG_ARCH_SUPPORTS_PMD_PFNMAP on 32-bit architectures. The problem was introduced by earlier commits that factored out common code but overlooked this architectural difference. The fix ensures vm_normal_page_pmd() and vm_normal_page_pud() check for actual implementation of pmd_special/pud_special, preventing these memory management inconsistencies.
Potential Impact
The vulnerability causes kernel warnings and bugs related to memory management on affected systems, including incorrect memory accounting and potential instability during memory reclaim. While no exploits in the wild are known, the issue can lead to system instability or crashes on 32-bit x86 systems with THP enabled due to improper page state handling.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Since this is a kernel-level issue, applying the official Linux kernel updates that address CVE-2026-64181 when available is recommended. Until then, consider disabling Transparent Huge Pages (THP) on affected 32-bit x86 systems as a temporary mitigation if feasible.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-jx9m-72fr-5v84
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-64181"]
- Ecosystems
- []
- Database Specific Severity
- null
- Cvss Version
- null
Threat ID: 6a5d27a82a4a8d598912a22b
Added to database: 07/19/2026, 19:38:16 UTC
Last enriched: 07/19/2026, 19:40:12 UTC
Last updated: 07/20/2026, 19:41:21 UTC
Views: 14
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.