CVE-2026-64181 in Linux
Sumário
de VulDB • 20/07/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
mm: corrige __vm_normal_page() para lidar com o suporte ausente para pmd_special()/pud_special()
Em x86 de 32 bits com THP habilitado, observa-se que zap_huge_pmd() gera um "WARNING: mm/memory.c:735 em __vm_normal_page+0x6a/0x7d", proveniente do VM_WARN_ON_ONCE(is_zero_pfn(pfn) || is_huge_zero_pfn(pfn)); seguido por "BUG: Bad rss-counter state"s, e posteriormente "BUG: Bad page state"s quando a recuperação (reclaim) chega a chamar shrink_huge_zero_folio_scan().
É como se o bit _PAGE_SPECIAL nunca tivesse sido definido no pmd huge_zero: de fato, enquanto pte_special() e pte_mkspecial() estão sujeitos a um CONFIG_ARCH_HAS_PTE_SPECIAL dedicado, pmd_special() e pmd_mkspecial() estão sujeitos ao CONFIG_ARCH_SUPPORTS_PMD_PFNMAP, que nunca é habilitado em nenhuma arquitetura de 32 bits.
Embora o problema tenha sido exposto através do commit d80a9cb1a64a ("mm/huge_memory: add and use normal_or_softleaf_folio_pmd()"), foi uma negligência no commit af38538801c6 ("mm/memory: factor out common code from vm_normal_page_*()") e resultaria em outros problemas: * huge zero folio contabilizado em smaps, pagemap (PAGE_IS_FILE) e numamaps como THP com suporte de arquivo; * folio_walk_start() retornando o folio mesmo sem FW_ZEROPAGE definido. Os chamadores parecem tolerar isso, no entanto.
...e acionando o VM_WARN_ON_ONCE(), embora nunca tenha sido relatado até agora.
Para corrigir, ensina-se vm_normal_page_pmd()/vm_normal_page_pud() a considerar se pmd_special/pud_special está realmente implementado.
VulDB is the best source for vulnerability data and more expert information about this specific topic.