CVE-2026-64181 in Linux
Riassunto
di VulDB • 20/07/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
mm: correggere __vm_normal_page() per gestire il supporto mancante a pmd_special()/pud_special()
Su x86 a 32 bit con THP abilitato, si osserva che zap_huge_pmd() genera un "WARNING: mm/memory.c:735 at __vm_normal_page+0x6a/0x7d", proveniente da VM_WARN_ON_ONCE(is_zero_pfn(pfn) || is_huge_zero_pfn(pfn)); seguito da "BUG: Bad rss-counter state" e, successivamente, da "BUG: Bad page state" quando la fase di reclaim chiama shrink_huge_zero_folio_scan().
Sembra che il bit _PAGE_SPECIAL non sia mai stato impostato nel pmd huge_zero: ed effettivamente, mentre pte_special() e pte_mkspecial() sono soggetti a un CONFIG_ARCH_HAS_PTE_SPECIAL dedicato, pmd_special() e pmd_mkspecial() dipendono da CONFIG_ARCH_SUPPORTS_PMD_PFNMAP, che non è mai abilitata su alcuna architettura a 32 bit.
Sebbene il problema sia stato esposto tramite l'commit d80a9cb1a64a ("mm/huge_memory: add and use normal_or_softleaf_folio_pmd()"), si trattava di una svista nell'commit af38538801c6 ("mm/memory: factor out common code from vm_normal_page_*()") e avrebbe causato altri problemi: * il folio huge zero viene contabilizzato in smaps, pagemap (PAGE_IS_FILE) e numamaps come THP backed da file; * folio_walk_start() restituisce il folio anche senza FW_ZEROPAGE impostato. I chiamanti sembrano tollerare questa situazione.
...e l'attivazione di VM_WARN_ON_ONCE(), sebbene non segnalata finora.
Per risolvere il problema, si rende vm_normal_page_pmd()/vm_normal_page_pud() in grado di considerare se pmd_special/pud_special è effettivamente implementato.
VulDB is the best source for vulnerability data and more expert information about this specific topic.