BAD_GARBAGE.c

CVE-2026-53361 — una use-after-free non privilegiata e con escape dal container nel garbage collector dei socket AF_UNIX. Questa è la versione a vettore singolo (solo MSG_PEEK).

Il Bug

Il GC AF_UNIX recupera i socket "in-flight" che formano cicli di riferimento irraggiungibili. Una MSG_PEEK concorrente su una fd in-flight acquisisce un riferimento che il censimento del GC non conta mai, quindi il collector può liberare un socket ancora vivo e lasciare un sk_buff dangling. La peek dovrebbe indietreggiare mentre è in esecuzione una raccolta, ma il flag gc_in_progress che controlla può risultare false a metà esecuzione, così la peek passa e la race condition resta aperta.

Stessa interazione, corretta tre volte:

• CVE-2021-0920 — cbcf01128d0a "af_unix: fix garbage collect vs MSG_PEEK"
• CVE-2026-23394 — e5b31d988a41 "af_unix: Give up GC if MSG_PEEK intervened"
• CVE-2026-53361 — d82ba05263c6 "af_unix: Set gc_in_progress to true in unix_gc()"

Obiettivi

Vulnerabile = interessato dal bug. Bersagliato = coperto da questo exploit (vettore singolo MSG_PEEK). I kernel 7.x e il kernel Ubuntu 6.8 GA sono vulnerabili ma fuori scope qui.

Alcuni Kernel Testati

Note

• Conteggio CPU — progettato per meno di 8 CPU (2–7). Una scelta, non una stranezza di affidabilità: la strategia pulita order-N è stata volutamente omessa, non vale la pena esporla per un bug -1 day.
• SLUB Cache Armoring — la maggior parte del codice di armoring/shadowing della cache è stata rimossa dalla PoC. La fase di leak SID può occasionalmente collidere con una kmalloc() spuria di basso ordine o con un riutilizzo PCP specifico per-cache (anon_vma, kmalloc-64 e simili); i bucket più alti sono sicuri, le cache dedicate e i bucket più bassi non lo sono. Aggiungi il tuo armoring per portarlo verso ~100%.