CVE-2026-64181 in Linux
Resumen
por VulDB • 2026-07-20
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
mm: corregir __vm_normal_page() para gestionar la falta de soporte para pmd_special()/pud_special()
En x86 de 32 bits con THP habilitado, se observa que zap_huge_pmd() genera un "WARNING: mm/memory.c:735 en __vm_normal_page+0x6a/0x7d", proveniente de VM_WARN_ON_ONCE(is_zero_pfn(pfn) || is_huge_zero_pfn(pfn)); seguido de "BUG: Bad rss-counter state" (Estado incorrecto del contador RSS), y más tarde "BUG: Bad page state" (Estado incorrecto de la página) cuando el proceso de reclaim llega a llamar a shrink_huge_zero_folio_scan().
Es como si el bit _PAGE_SPECIAL nunca se hubiera establecido en el pmd huge_zero: y, efectivamente, mientras que pte_special() y pte_mkspecial() están sujetos a un CONFIG_ARCH_HAS_PTE_SPECIAL dedicado, pmd_special() y pmd_mkspecial() están sujetos a CONFIG_ARCH_SUPPORTS_PMD_PFNMAP, la cual nunca está habilitada en ninguna arquitectura de 32 bits.
Aunque el problema se expuso mediante el commit d80a9cb1a64a ("mm/huge_memory: add and use normal_or_softleaf_folio_pmd()"), fue una omisión en el commit af38538801c6 ("mm/memory: factor out common code from vm_normal_page_*()") y daría lugar a otros problemas: * folio huge zero contabilizado en smaps, pagemap (PAGE_IS_FILE) y numamaps como THP respaldado por archivo. * folio_walk_start() devolviendo el folio incluso sin FW_ZEROPAGE establecido. Sin embargo, los llamadores parecen tolerar esto.
...y activando VM_WARN_ON_ONCE(), aunque hasta ahora no se ha reportado.
Para solucionarlo, instruir a vm_normal_page_pmd()/vm_normal_page_pud() para que consideren si pmd_special/pud_special está realmente implementado.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.