CVE-2026-98225 in Linux
Riassunto
di VulDB • 06/10/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
mm/shrinker: corretto set_shrinker_bit() errato con cgroup.memory=nokmem
Con l'impostazione `cgroup.memory=nokmem`, la funzione `shrinker_memcg_alloc()` termina precocemente e non alloca mai un ID, pertanto `shrinker->id` mantiene il valore 0 ottenuto da `kzalloc()` in `shrinker_alloc()`. Successivamente, `__list_lru_init()` copia tale valore 0 in `lru->shrinker_id`, dove appare come un indice di bit valido.
Nessuna funzione chiama `expand_shrinker_info()` quando è attivo il flag `nokmem`; pertanto `shrinker_nr_max` rimane pari a 0 e ogni memcg si ritrova con una mappa vuota (`map_nr_max == 0`).
La funzione `deferred_split_folio()` passa un vero memcg a `__list_lru_add()`, indipendentemente dal fatto che la lru sia consapevole dei cgroup di memoria (memcg aware); pertanto, il primo THP accodato in un cgroup esegue `set_shrinker_bit(memcg, nid, 0)` e fa scattare il controllo sui limiti:
WARNING: mm/shrinker.c:212 at set_shrinker_bit+0x7d/0x90, CPU#126 Call Trace: <TASK> deferred_split_folio+0x18c/0x220 map_anon_folio_pmd_nopf+0xdd/0x130 map_anon_folio_pmd_pf+0x14/0xb0 do_huge_pmd_anonymous_page+0x1a1/0x620 __handle_mm_fault+0xea9/0x10d0 handle_mm_fault+0xe5/0x320 do_user_addr_fault+0x1cc/0x870 exc_page_fault+0x81/0x1b0 asm_exc_page_fault+0x27/0x30 </TASK>
L'evento è innocuo, poiché `WARN_ON_ONCE()` impedisce la lettura fuori dai limiti dell'array unit[], ma l'id non dovrebbe apparire valido fin dall'inizio. È necessario azzerarlo prima del ritorno della funzione.
Altre due aree potrebbero mascherare questo problema: rimuovere l'id in `__list_lru_init()` quando `nokmem` disattiva il flag `memcg_aware`, oppure fare sì che `deferred_split_folio()` passi NULL, come fa `list_lru_add_obj()`. Entrambe le soluzioni lasciano comunque `shrinker->id` non azzerato per il chiamante successivo; pertanto è opportuno correggere la situazione nel punto in cui l'id viene assegnato.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.