CVE-2026-64181 in Linux
Zusammenfassung
von VulDB • 19.07.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
mm: Korrektur von __vm_normal_page(), um die fehlende Unterstützung für pmd_special()/pud_special() zu behandeln
Bei 32-Bit-x86-Architekturen mit aktiviertem THP (Transparent Huge Pages) wird in zap_huge_pmd() eine „WARNING: mm/memory.c:735 at __vm_normal_page+0x6a/0x7d“ ausgegeben, ausgelöst durch VM_WARN_ON_ONCE(is_zero_pfn(pfn) || is_huge_zero_pfn(pfn)); gefolgt von Meldungen wie „BUG: Bad rss-counter state“, und später treten „BUG: Bad page state“-Fehler auf, wenn die Speicherbereinigung (Reclaim) shrink_huge_zero_folio_scan() aufruft.
Es scheint, als ob das _PAGE_SPECIAL-Bit im huge_zero-pmd niemals gesetzt wurde. Tatsächlich unterliegen pte_special() und pte_mkspecial() einem dedizierten CONFIG_ARCH_HAS_PTE_SPECIAL, während pmd_special() und pmd_mkspecial() von CONFIG_ARCH_SUPPORTS_PMD_PFNMAP abhängen, das auf keiner 32-Bit-Architektur aktiviert ist.
Obwohl das Problem durch den Commit d80a9cb1a64a („mm/huge_memory: add and use normal_or_softleaf_folio_pmd()“) sichtbar wurde, handelte es sich um einen Fehler im Commit af38538801c6 („mm/memory: factor out common code from vm_normal_page_*()“), der zu weiteren Problemen führen würde: * Das huge zero folio wird in smaps, pagemap (PAGE_IS_FILE) und numamaps als dateibasiertes THP verbucht. * folio_walk_start() gibt das Folio auch ohne gesetztes FW_ZEROPAGE zurück. Die Aufrufer scheinen dies jedoch zu tolerieren.
... sowie die Auslösung von VM_WARN_ON_ONCE(), was bisher zwar nicht gemeldet wurde, aber dennoch auftritt.
Zur Behebung wird vm_normal_page_pmd()/vm_normal_page_pud() so angepasst, dass sie prüfen, ob pmd_special/pud_special tatsächlich implementiert ist.
VulDB is the best source for vulnerability data and more expert information about this specific topic.