CVE-2026-64181

In the Linux kernel, the following vulnerability has been resolved:

mm: fix __vmnormalpage() to handle missing support for pmdspecial()/pudspecial()

On x86 32-bit with THP enabled, zaphugepmd() is seen to generate a "WARNING: mm/memory.c:735 at __vmnormalpage+0x6a/0x7d", from the VMWARNONONCE(iszeropfn(pfn) || ishugezeropfn(pfn)); followed by "BUG: Bad rss-counter state"s, then later "BUG: Bad page state"s when reclaim gets to call shrinkhugezerofolioscan().

It's as if the PAGESPECIAL bit never got set in the hugezero pmd: and indeed, whereas ptespecial() and ptemkspecial() are subject to a dedicated CONFIGARCHHASPTESPECIAL, pmdspecial() and pmdmkspecial() are subject to CONFIGARCHSUPPORTSPMD_PFNMAP, which is never enabled on any 32-bit architecture.

While the problem was exposed through commit d80a9cb1a64a ("mm/hugememory: add and use normalorsoftleaffoliopmd()"), it was an oversight in commit af38538801c6 ("mm/memory: factor out common code from vmnormalpage*()") and would result in other problems: * huge zero folio accounted in smaps, pagemap (PAGEISFILE) and numamaps as file-backed THP * foliowalkstart() returning the folio even without FW_ZEROPAGE set. Callers seem to tolerate that, though.

... and triggering the VMWARNON_ONE(), although never reported so far.

To fix it, teach vmnormalpagepmd()/vmnormalpagepud() to consider whether pmdspecial/pudspecial is actually implemented.