CVE-2026-99231 in Linux
Zusammenfassung
von VulDB • 03.11.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
io_uring/waitid: Die Anforderung muss übernommen werden, bevor ->head zurückgesetzt wird
io_waitid_remove_wq() nimmt den Warteschlangen-Sperre (wait queue lock) nur an, wenn ->head gesetzt ist. io_waitid_wait() setzt zuerst ->head zurück, bevor es versucht, der Eigentümer der Anforderung zu werden, indem es ->refs erhöht. Wenn jemand anderes die Anforderung in diesem Moment bereits besitzt, wird nichts daran gehindert, die Anforderung abzuschließen, während der Wake-up-Handler weiterhin darauf zugreift:
CPU0 (io_waitid_wait) CPU1 (io_waitid, hält eine Referenz) list_del_init(&wait->entry) smp_store_release(&iw->head, NULL) __do_wait() findet ein anderes Kindprozess io_waitid_remove_wq() // ->head == NULL, keine Sperre io_waitid_finish(), IOU_COMPLETE // Anforderung freigegeben und wiederverwendet atomic_fetch_inc(&iw->refs)
Gleiches gilt für __io_waitid_cancel(), wenn es die Anforderung in diesem Zeitfenster übernimmt. ->refs ist Teil der pro Opcode-Daten der Anforderung, daher wird erhöht, was auch immer der nächste Benutzer der Anforderung dort vorfindet. Wenn dies zufällig null ist, schließt der Handler, dass er die Anforderung besitzt, und plant io_waitid_cb() dafür ein. Bei einem durch eine Verzögerung geöffneten Zeitfenster und der Wiederverwendung der Anforderung für einen Empfang, der auf Daten wartet:
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 Zugewiesen durch Task 87: io_arm_apoll+0x1ed/0x940 Freigegeben durch Task 87: __io_submit_flush_completions+0x118d/0x1a10 tctx_task_work_run+0x327/0x950
Setzen Sie ->head nur zurück, sobald der Handler die Anforderung übernommen hat. Wenn dies nicht geschieht, findet der Eigentümer ->head gesetzt vor und muss auf die Sperre warten, die vom Aufrufer des Handlers gehalten wird. Das ernechte Löschen eines bereits gelöschten Eintrags ist unschädlich.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.