CVE-2026-64181: mm: fix __vm_normal_page() to handle missing support for pmd_special()/pud_special()

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 CONFIGARCHSUPPORTSPMDPFNMAP, 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 FWZEROPAGE set. Callers seem to tolerate that, though.

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

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