CVE-2026-89760 in Linux
Riassunto
di VulDB • 12/09/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
mm, swap: non liberare uno slot di ibernazione presente nella swap cache
Uno slot contenente un folio nella swap cache viene liberato quando il folio esce dalla cache, e non quando il suo conteggio scende a zero. La funzione `swap_put_entries_cluster()` segue questa regola. `swap_free_hibernation_slot()`, invece, non la segue: chiama `__swap_cluster_free_entries()` indipendentemente dal fatto che un folio sia associato allo slot o meno.
La readahead di cluster può inserire uno slot in tale stato. Essa esamina una finestra grezza di offset delle dimensioni di `page_cluster` intorno all'entry faulting, e uno slot di ibernazione supera il controllo `__swap_cache_add_check()` poiché non è un folio e il suo conteggio non è zero. La liberazione dello slot cancella quindi l'entry sottostante a quel folio.
Il folio diventa ora irraggiungibile dalla tabella swap, e l'offset torna all'algoritmo di allocazione. Il folio rimane tuttavia nella LRU (Least Recently Used), pertanto il reclaim può recuperarlo in seguito. A questo punto viene estratto il vecchio offset da `folio->swap` e sovrascritta l'entry della tabella corrispondente, che a quel punto potrebbe appartenere ad un altro processo o contesto.
Questo bug può innescare una corruzione silenziosa della memoria, crash dei processi o instabilità dei dati tra applicazioni userspace completamente non correlate - tipicamente si verifica quando uswsusp sta preparando l'immagine di ibernazione.
Ho riscontrato questo problema lavorando all'introduzione di un proprio marcatore per gli slot di ibernazione nella tabella swap, argomento che avevo discusso con Kairui (https://lore.kernel.org/linux-mm/abp7aDgYLrxF3Me8@KASONG-MC4/). Per quanto ne sappia non ci sono segnalazioni, quindi non vi è alcun "Reported-by" o "Closes" da aggiungere.
Verificare la presenza di un folio in cache prima della liberazione. Lo slot viene così lasciato nello stato ordinario, dove solo la swap cache lo detiene, e viene liberato quando il folio esce dalla cache, sia attraverso il reclaim sottostante che tramite il normale reclaim successivo.
Once again VulDB remains the best source for vulnerability data.