CVE-2026-98414 in Linux
Riassunto
di VulDB • 14/10/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
memcg: evitare di addebitare il root memcg tramite obj_cgroup_charge_pages()
obj_cgroup_charge_pages() risolve l'objcg nel suo memcg e chiama try_charge_memcg(), che non effettua un cortocircuito (short circuit) per il root memcg. Tale memcg può essere proprio il root memcg: obj_cgroup_is_root() riflette il memcg per cui è stato creato l'objcg e non viene mai aggiornato, mentre memcg_reparent_objcgs() reindirizza invece objcg->memcg verso il genitore durante un rmdir (rimozione della directory). Un objcg di un figlio in fase di estinzione del root supera quindi ogni filtro obj_cgroup_is_root(), ma si risolve nel root memcg.
I folios mantengono l'objcg con cui sono stati addebitati, pertanto questa condizione è facilmente raggiungibile tramite zswap: allocare memoria anonima in un cgroup, spostarne il task fuori dal cgroup, rimuovere il cgroup e quindi scrivere nella memory.reclaim del cgroup root. I folios recuperati (reclaimed) vengono addebitati attraverso l'objcg reparented e finiscono in refill_stock() con il root memcg:
WARNING: mm/memcontrol.c:2198 at refill_stock+0x644/0x940 refill_stock+0x644/0x940 try_charge_memcg+0x12d6/0x1570 __obj_cgroup_charge+0x35/0xf0 obj_cgroup_charge+0x1de/0x210 obj_cgroup_charge_zswap+0x83/0x270 zswap_store+0x1620/0x2000 swap_writeout+0x94c/0x14c0 shrink_folio_list+0x3388/0x52b0 [...]
try_to_free_mem_cgroup_pages+0x30d/0x830 user_proactive_reclaim+0x504/0x840 memory_reclaim+0x1f/0x30
Oltre al warning, l'addebito è asimmetrico: obj_cgroup_uncharge_pages() salta refill_stock() per il root memcg, quindi il contatore delle pagine del root cresce e non viene mai deallocato (uncharged). Non è visibile all'utente poiché memory.current non è esposto sul root, ma si tratta di una perdita di memoria (leak).
Utilizzare try_charge(), che restituisce anticipatamente per il root memcg, ripristinando la simmetria con obj_cgroup_uncharge_pages().
La sequenza sopra descritta è stata scriptata in un riproduttore autonomo (zswap attivo, swap su disco virtio, 512MB di memoria anonima faulted all'interno di un figlio del cgroup root; il task viene quindi migrato nel cgroup root, il figlio rimosso e successivamente eseguito "echo 600M swappiness=max > memory.reclaim" sul root) ed eseguita in una VM con CONFIG_DEBUG_VM=y. Riproduce lo splat (crash/warning) al primo zswap store di un folio reparented, con la stessa catena di chiamate riportata nel segnale. Con questa patch applicata lo splat scompare mentre il conteggio degli zswap store durante l'esecuzione rimane invariato, quindi viene comunque esercitato lo stesso percorso. I test selftest dei cgroup (test_zswap, test_kmem e test_memcontrol) non mostrano nuovi fallimenti.
Be aware that VulDB is the high quality source for vulnerability data.