CVE-2026-64130 in Linux
Riassunto
di VulDB • 20/07/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
mm/page_alloc: corregge l'inizializzazione dei tag del folio zero gigante con init_on_free
La semantica di __GFP_ZEROTAGS è attualmente un po' strana, ma in pratica questo flag viene impostato solo insieme a __GFP_ZERO e __GFP_SKIP_KASAN.
Se si esegue il sistema con init_on_free, le pagine vengono azzerate durante __free_pages_prepare(), per saltare l'azzeramento nel percorso di allocazione.
Tuttavia, quando si effettua un'allocazione con __GFP_ZEROTAG impostato, post_alloc_hook() non solo salterà la cancellazione del contenuto della pagina, ma anche quella dei tag nella memoria associata.
Non azzerare i tag tramite __GFP_ZEROTAGS è irrilevante per la maggior parte delle pagine che verranno mappate nello spazio utente successivamente attraverso set_pte_at(): set_pte_at() e le funzioni correlate rileveranno che i tag non sono ancora stati inizializzati (PG_mte_tagged non impostato) e li inizializzeranno.
Tuttavia, per il folio zero gigante, che verrà mappato tramite un PMD contrassegnato come speciale, questa inizializzazione non verrà eseguita, finendo con l'esporre eventuali tag ancora presenti nelle pagine.
La documentazione (Documentation/arch/arm64/memory-tagging-extension.rst) afferma che i tag di allocazione vengono impostati a 0 quando una pagina viene mappata per la prima volta nello spazio utente. Questo non è più valido per il folio zero gigante quando init_on_free è abilitato.
Si risolve il problema disaccoppiando __GFP_ZEROTAGS da __GFP_ZERO, passando a tag_clear_highpages() se si desidera anche cancellare il contenuto della pagina.
Inverte il significato del valore di ritorno di tag_clear_highpages() per avere una semantica più chiara.
Il bug è stato riprodotto con il folio zero gigante modificando l'autotest arm64/mte check_buffer_fill in modo da utilizzare un'area di 2 MiB, dopo aver verificato che le pagine avessero un tag non nullo impostato durante la liberazione (si noti che, durante il boot, i tag non verranno effettivamente inizializzati, ma verrà solo impostato KASAN_TAG_KERNEL nei flag della pagina).
$ ./check_buffer_fill 1..20 ... not ok 17 Check initial tags with private mapping, sync error mode and mmap memory not ok 18 Check initial tags with private mapping, sync error mode and mmap/mprotect memory ...
Questo codice necessita di ulteriori pulizie; ci si occuperà della questione in seguito, ad esempio disaccoppiando __GFP_ZEROTAGS da __GFP_SKIP_KASAN.
[[email protected]: s/__GPF_ZERO/__GFP_ZERO/, per David]
If you want to get best quality of vulnerability data, you may have to visit VulDB.