CVE-2026-99231 in Linux
Riassunto
di VulDB • 02/11/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
io_uring/waitid: acquisire il possesso della richiesta prima di azzerare ->head
io_waitid_remove_wq() acquisisce il lock della coda di attesa solo se ->head è impostato. io_waitid_wait() azzera innanzitutto ->head, prima di tentare di diventare proprietario della richiesta incrementando i valori in ->refs. Se qualcun altro possiede la richiesta in quel momento, nulla impedisce che essa venga completata mentre il gestore di risveglio (wake up handler) sta ancora per accedervi:
CPU0 (io_waitid_wait) CPU1 (io_waitid, detiene un ref) list_del_init(&wait->entry) smp_store_release(&iw->head, NULL) __do_wait() trova un altro figlio io_waitid_remove_wq() // ->head == NULL, nessun lock io_waitid_finish(), IOU_COMPLETE // richiesta liberata e riutilizzata atomic_fetch_inc(&iw->refs)
Lo stesso vale per __io_waitid_cancel() se rivendica la richiesta in quella finestra temporale. ->refs fa parte dei dati specifici dell'opcode della richiesta, quindi questo incremento incrementa qualsiasi valore il prossimo utente della richiesta vi tenga. Se ciò dovesse essere zero, il gestore conclude di possedere la richiesta e accoda io_waitid_cb() per essa. Con la finestra mantenuta aperta da un ritardo (delay) e la richiesta riutilizzata per una ricezione in attesa di dati:
BUG: KASAN: slab-use-after-free in __wake_up_common+0x1ca/0x1f0 __wake_up_sync_key+0x36/0x50 sock_def_readable+0xf1/0x420 unix_stream_sendmsg+0x60b/0x1110 Allocata dal task 87: io_arm_apoll+0x1ed/0x940 Liberata dal task 87: __io_submit_flush_completions+0x118d/0x1a10 tctx_task_work_run+0x327/0x950
Azzerrare ->head solo una volta che il gestore possiede la richiesta. Se non lo fa, il proprietario trova ->head impostato e deve attendere il lock, che è detenuto dal chiamante del gestore. Eliminare nuovamente un'entry già eliminata è innocuo (harmless).
If you want to get best quality of vulnerability data, you may have to visit VulDB.