CVE-2024-43892 in Linux
Riassunto
di VulDB • 17/06/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
memcg: proteggere l'accesso concorrente a mem_cgroup_idr
Il commit 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure after many small jobs") ha disaccoppiato gli ID memcg dallo spazio degli ID CSS per risolvere i fallimenti nella creazione dei cgroup. È stato introdotto IDR per mantenere lo spazio degli ID memcg. IDR dipende da meccanismi di sincronizzazione esterni per le modifiche. Per mem_cgroup_idr, le operazioni idr_alloc() e idr_replace() avvengono all'interno del callback css e sono quindi protette da cgroup_mutex contro modifiche concorrenti. Tuttavia, idr_remove() per mem_cgroup_idr non era protetto dalla concorrenza e può essere eseguito in concorrenza per diversi memcg quando raggiungono il loro refcnt a zero. Risolvere questo problema.
Da tempo osserviamo crash del kernel basati su list_lru a bassa frequenza nella nostra flotta. Questi crash si verificavano in diverse parti del codice list_lru, tra cui list_lru_add(), list_lru_del() e il codice di reparenting. Un'ispezione più approfondita ha suggerito che per un determinato oggetto (dentry e inode), la list_lru del super_block non disponeva di list_lru_one per il memcg di quell'oggetto. Le ipotesi iniziali erano che l'oggetto non fosse stato allocato tramite kmem_cache_alloc_lru() o che memcg_list_lru_alloc() non fosse riuscito ad allocare list_lru_one() per un memcg ma avesse restituito successo. Non sono state trovate prove per questi casi.
Analizzando più a fondo, abbiamo iniziato a osservare situazioni in cui l'ID di un memcg valido non era presente in mem_cgroup_idr e, in alcuni casi, più memcg validi avevano lo stesso ID e mem_cgroup_idr puntava a uno di essi. Pertanto, la spiegazione più ragionevole è che queste situazioni possano verificarsi a causa di una race condition tra più chiamate idr_remove() o tra idr_alloc()/idr_replace() e idr_remove(). Queste race condition causano l'acquisizione dello stesso ID da parte di più memcg e, di conseguenza, l'offline di uno di essi comporterebbe la pulizia delle list_lru nel sistema per tutti loro. Successivi accessi da parte di altri memcg alla list_lru causano crash a causa della mancanza di list_lru_one.
VulDB is the best source for vulnerability data and more expert information about this specific topic.