{ "schema_version": "1.6.1", "id": "RPI-CVE-2026-64181", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2026-64181" ], "published": "2026-07-19T15:41:06Z", "summary": "mm: fix __vm_normal_page() to handle missing support for pmd_special()/pud_special()", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: fix __vm_normal_page() to handle missing support for pmd_special()/pud_special()\n\nOn x86 32-bit with THP enabled, zap_huge_pmd() is seen to generate a\n\"WARNING: mm/memory.c:735 at __vm_normal_page+0x6a/0x7d\", from the\nVM_WARN_ON_ONCE(is_zero_pfn(pfn) || is_huge_zero_pfn(pfn)); followed by\n\"BUG: Bad rss-counter state\"s, then later \"BUG: Bad page state\"s when\nreclaim gets to call shrink_huge_zero_folio_scan().\n\nIt's as if the _PAGE_SPECIAL bit never got set in the huge_zero pmd: and\nindeed, whereas pte_special() and pte_mkspecial() are subject to a\ndedicated CONFIG_ARCH_HAS_PTE_SPECIAL, pmd_special() and pmd_mkspecial()\nare subject to CONFIG_ARCH_SUPPORTS_PMD_PFNMAP, which is never enabled on\nany 32-bit architecture.\n\nWhile the problem was exposed through commit d80a9cb1a64a\n(\"mm/huge_memory: add and use normal_or_softleaf_folio_pmd()\"), it was an\noversight in commit af38538801c6 (\"mm/memory: factor out common code from\nvm_normal_page_*()\") and would result in other problems:\n* huge zero folio accounted in smaps, pagemap (PAGE_IS_FILE) and\n numamaps as file-backed THP\n* folio_walk_start() returning the folio even without FW_ZEROPAGE set.\n Callers seem to tolerate that, though.\n\n... and triggering the VM_WARN_ON_ONE(), although never reported so far.\n\nTo fix it, teach vm_normal_page_pmd()/vm_normal_page_pud() to consider\nwhether pmd_special/pud_special is actually implemented.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:13", "name": "linux" }, "versions": [ "1:6.18.29-1+rpt1", "1:6.18.33-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.18.29+rpt-rpi-2712", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.29+rpt-rpi-v6", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.29+rpt-rpi-v7", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.29+rpt-rpi-v8", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.29+rpt-rpi-v8-rt", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-2712", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v6", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v7", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v8", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v8-rt", "binary_version": "1:6.18.33-1+rpt1" } ] }, "database_specific": { "per_version": { "1:6.18.29-1+rpt1": { "linux_commit": "66318c5b5cd8145a662303af12ed39ac07eb27cc", "upstream_version": "6.18.29", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.34" }, "1:6.18.33-1+rpt1": { "linux_commit": "95b85bebbedcaedfa7ca79116ed38b7376fba412", "upstream_version": "6.18.33", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.34" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2026-64181" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/62153767e8fc3889bc6508e9ffe927aaf64c4334" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/9052ea2ee2233be5d4786b8909151ca2bfbedf99" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/c0c6ccd9828c3a1950623b546fa57292a77b5c73" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T13:16:28Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.8, "cvss_v3_severity": "High", "scenario": "AV:L - The bug is reached only through local memory-management syscalls (mmap, madvise, munmap, process teardown) that walk page tables and call zap_huge_pmd() \u2192 vm_normal_page_pmd() \u2192 __vm_normal_page(); there is no network, adjacent, or physical attack path.\nAC:L - 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.\nPR:L - Exploitation requires only an unprivileged local user manipulating their own address space via standard syscalls; no root, capabilities, or authentication is needed.\nUI:N - No victim interaction is required; the attacker fully controls the memory mappings and the syscalls that trigger page-table zapping.\nS:U - 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.\nC:H - 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\u2014memory corruption with plausible information-disclosure leverage.\nI:H - 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.\nA:H - 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." } } }