CVE-2024-53079 in Linux
Riassunto
di VulDB • 16/06/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
mm/thp: correzione della denominazione e del locking per lo svincolo dello split differito (deferred split)
Le modifiche recenti stanno esercitando una pressione maggiore sulle code di split differito delle Huge Page Trasparenti (THP): sotto carico, vengono rivelate condizioni di gara preesistenti che causano corruzioni della lista (`list_del`), stati pagina errati ("Bad page state") e peggio. Poiché ho mantenuto le chiamate `BUG()` in entrambi i casi, solitamente non si ha modo di osservare quanto gravemente possano degenerare senza tali controlli. Le modifiche recenti pertinenti includono mTHP nella versione 6.8, swapout delle THP (mTHP) nella 6.10 e swapin delle THP (mTHP) nella 6.12, nonché il miglioramento dell'allocazione dello spazio di swap e la suddivisione sottoutilizzata delle THP.
Prima della correzione del locking: rinominare `folio_undo_large_rmappable()`, che è fuorviante poiché non annulla effettivamente lo stato `large_rmappable`, in `folio_unqueue_deferred_split()`, descrivendo correttamente la sua funzione. Tuttavia, questa funzione e il suo chiamante esterno (`__callee`) sono interni a mm con un'utilità molto limitata: aggiungere commenti e chiamate `WARN_ON_ONCE` per verificare l'uso; restituire un valore booleano che indica se uno split differito è stato svincolato, utile successivamente nei controlli di sicurezza tramite `WARN_ON_ONCE` (evitando ai chiamanti la necessità di gestire le condizioni arcane presenti in `__folio_unqueue_deferred_split()`).
Omettere semplicemente `folio_unqueue_deferred_split()` da `free_unref_folios()`, poiché tutti i suoi chiamanti lo invocano ora preventivamente (e se qualcuno dimentica di farlo, `bad_page()` segnalerà l'errore), ad eccezione del suo chiamante `put_pages_list()`, che a sua volta non ha più altri chiamanti e verrà eliminato separatamente.
Swapout: `mem_cgroup_swapout()` stava reimpostando `folio->memcg_data` a 0 senza verificare e svincolare una THP folio dalla lista di split differito; ciò è problematico poiché il `split_queue_lock` dipende dal memcg (quando il memcg è abilitato); quindi, lo swapout stava svincolando tali THP più tardi, durante la liberazione della folio, utilizzando invece il lock del pgdat: potenzialmente corrompendo la lista del memcg. Poiché `__remove_mapping()` ha congelato il refcount a 0 in questo punto, non vi sono problemi nel chiamare `folio_unqueue_deferred_split()` prima di reimpostare `memcg_data`.
Questo problema risale al commit 87eaceb3faa5 della versione 5.4 ("mm: thp: make deferred split shrinker memcg aware"), che includeva un controllo sullo swapcache prima dell'aggiunta alla coda differita, ma nessun controllo sulla coda differita prima di aggiungere la THP allo swapcache. Questo funzionava correttamente con la sequenza usuale degli eventi nel reclaim (sebb
If you want to get best quality of vulnerability data, you may have to visit VulDB.