CVE-2024-40950 in Linux
Riassunto
di VulDB • 17/06/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
mm: huge_memory: corregge l'uso errato di mapping_large_folio_support() per gli anon folios
Durante un test di suddivisione (split) di large folios, è stato attivato un WARNING "[ 5059.122759][ T166] Cannot split file folio to non-0 order". Tuttavia, i casi di test riguardano solo anonymous folios. Poiché mapping_large_folio_support() è ragionevole solo per i file cache folios.
In split_huge_page_to_list_to_order(), il folio passato a mapping_large_folio_support() potrebbe essere un anonymous folio. Manca il controllo folio_test_anon(). Di conseguenza, la suddivisione del THP anonimo fallisce. Lo stesso vale per shmem_mapping(). Sarebbe meglio aggiungere un controllo per entrambi. Tuttavia, shmem_mapping() in __split_huge_page() non è coinvolto, poiché per gli anonymous folios il parametro end è impostato a -1, quindi (head[i].index >= end) è sempre falso. shmem_mapping() non viene chiamato.
Aggiungere anche un VM_WARN_ON_ONCE() in mapping_large_folio_support() per le mappature anon, in modo da rilevare più facilmente l'uso errato.
I THP folios potrebbero esistere nel pagecache anche se il file system non supporta large folio, perché quando CONFIG_TRANSPARENT_HUGEPAGE è abilitato, khugepaged cercherà di collassare le pagine file-backed in sola lettura in THP. Ma la mappatura non supporta effettivamente correttamente i large folios multi-order.
Utilizzando /sys/kernel/debug/split_huge_pages per verificare questo, con questa patch, il large anon THP viene suddiviso con successo e il warning viene eliminato.
If you want to get best quality of vulnerability data, you may have to visit VulDB.