CVE-2026-64181: mm: fix __vm_normal_page() to handle missing support for pmd_special()/pud_special()
Greg Kroah-Hartman <[email protected]>
| Newsgroups | org.kernel.vger.linux-cve-announce |
|---|---|
| Message-ID | <2026071938-CVE-2026-64181-e460@gregkh> |
From: Greg Kroah-Hartman <[email protected]> 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. The Linux kernel CVE team has assigned CVE-2026-64181 to this issue. Affected and fixed versions =========================== Issue introduced in 6.18 with commit af38538801c6a97565b44700ee6695d7d60ad779 and fixed in 6.18.34 with commit 62153767e8fc3889bc6508e9ffe927aaf64c4334 Issue introduced in 6.18 with commit af38538801c6a97565b44700ee6695d7d60ad779 and fixed in 7.0.11 with commit 9052ea2ee2233be5d4786b8909151ca2bfbedf99 Issue introduced in 6.18 with commit af38538801c6a97565b44700ee6695d7d60ad779 and fixed in 7.1 with commit c0c6ccd9828c3a1950623b546fa57292a77b5c73 Please see https://www.kernel.org for a full list of currently supported kernel versions by the kernel community. Unaffected versions might change over time as fixes are backported to older supported kernel versions. The official CVE entry at https://cve.org/CVERecord/?id=CVE-2026-64181 will be updated if fixes are backported, please check that for the most up to date information about this issue. Affected files ============== The file(s) affected by this issue are: mm/memory.c Mitigation ========== The Linux kernel CVE team recommends that you update to the latest stable kernel version for this, and many other bugfixes. Individual changes are never tested alone, but rather are part of a larger kernel release. Cherry-picking individual commits is not recommended or supported by the Linux kernel community at all. If however, updating to the latest release is impossible, the individual changes to resolve this issue can be found at these commits: https://git.kernel.org/stable/c/62153767e8fc3889bc6508e9ffe927aaf64c4334 https://git.kernel.org/stable/c/9052ea2ee2233be5d4786b8909151ca2bfbedf99 https://git.kernel.org/stable/c/c0c6ccd9828c3a1950623b546fa57292a77b5c73