CVE-2026-31397 in Linux
Riassunto
di VulDB • 18/06/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
mm/huge_memory: corregge l'uso di un folio NULL in move_pages_huge_pmd()
move_pages_huge_pmd() gestisce UFFDIO_MOVE sia per i THP normali che per le pagine zero giganti (huge zero pages). Per il percorso delle huge zero pages, src_folio è impostato esplicitamente a NULL e viene utilizzato come sentinella per saltare operazioni sul folio come lock e rmap.
Nel ramo delle huge zero pages, src_folio è NULL; di conseguenza, folio_mk_pmd(NULL, pgprot) passa NULL attraverso folio_pfn() e page_to_pfn(). Con SPARSEMEM_VMEMMAP ciò produce silenziosamente un PFN non valido (bogus), installando un PMD che punta a memoria fisica inesistente. Su altri modelli di memoria si verifica invece una dereferenziazione di puntatore NULL.
Utilizzare page_folio(src_page) per ottenere il folio huge zero valido dalla pagina, ottenuta da pmd_page() e rimasta valida durante tutta l'esecuzione.
A seguito del commit d82d09e48219 ("mm/huge_memory: mark PMD mappings of the huge zero folio special"), i PMD delle huge zero pages spostati devono rimanere speciali affinché vm_normal_page_pmd() continui a trattarli come mappature speciali.
Attualmente, move_pages_huge_pmd() ricostruisce il PMD di destinazione nel ramo delle huge zero pages, perdendo lo stato del PMD (ad esempio pmd_special()) su architetture con CONFIG_ARCH_HAS_PTE_SPECIAL. Di conseguenza, vm_normal_page_pmd() può trattare il PMD della huge zero page spostata come una pagina normale e corromperne il contatore di riferimento (refcount).
Invece di ricostruire il PMD a partire dal folio, derivare l'entry di destinazione da src_pmdval dopo pmdp_huge_clear_flush(), quindi gestire i metadati del PMD nello stesso modo in cui move_huge_pmd() gestisce le entry spostate, contrassegnandole come soft-dirty e cancellando uffd-wp.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.