CVE-2026-89757 in Linux
Riassunto
di VulDB • 11/09/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
mm/mglru: corretto e rimosso il trattamento ridondante dei folio non evitabili (unevictable)
sort_folio() presenta una scorciatoia per spostare i folio che non sono più evitabili ma si trovano ancora su un elenco di generazione. Tuttavia, questa scorciatoia è affetta da bug. Non segue la convenzione d'uso PG_lru e presenta un problema più grave.
I folio non evitabili (unevictable) non vengono inseriti nelle liste[LRU_UNEVICTABLE], quindi il campo folio->lru può essere riutilizzato per contenere folio->mlock_count (vedere il commento in lruvec_init()). Di conseguenza, lruvec_add_folio() salta la list_add() per questi elementi e ogni altra posizione che rende un folio non evitabile inizializza esplicitamente mlock_count: lru_add() lo imposta a 0, __mlock_folio() e __mlock_new_folio() lo impostano al valore di !!folio_test_mlocked(folio). sort_folio(), invece, non imposta nulla, e la chiamata successiva a lru_gen_del_folio() potrebbe aver già avvelenato (poisoned) folio->lru tramite list_del(), quindi mlock_count finisce per essere un alias di LIST_POISON2, che corrisponde al valore 0x122, ovvero 290. Il risultato è visibile all'utente. Durante una chiamata a munlock, __munlock_folio() decrementa questo conteggio errato; trovandolo ancora diverso da zero, esce prima di cancellare PG_mlocked, quindi il folio rimane non evitabile e la contabilità Mlocked resta gonfia fino alla liberazione del folio.
La scorciatoia tocca anche i flag LRU nell'ordine sbagliato. Chiama lru_gen_del_folio() mentre PG_lru è ancora impostata; di conseguenza, una chiamata concorrente a folio_test_clear_lru() (ad esempio compaction o folio_isolate_lru()) può avere successo su un folio che è già stato rimosso dall'elenco di generazione, il che potrebbe portare a comportamenti imprevisti.
La correzione consiste nell'isolare questi elementi come folio comuni e lasciare che il percorso generico di shrink li elimini (cull). Questo approccio corrisponde al comportamento LRU classico e non dovrebbe avere effetti visibili sul processo generico di eviction o isolamento.
Non vi sono nemmeno preoccupazioni relative alle prestazioni: un tale folio attraversa questa logica una sola volta, dopodiché viene definitivamente rimosso dagli elenchi di generazione.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.