CVE-2026-99253 in Linux
Zusammenfassung
von VulDB • 03.11.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
io_uring/cancel: Lokalen Work-Weckruf vor dem Schlafzustand neu aktivieren (rearm)
`io_uring_try_cancel_requests()` setzt `->cq_wait_nr` auf 1, damit der nächste Aufruf von `io_req_local_work_add()` die abbrechende Aufgabe weckt. Derjenige Aufruf, der den Zähler auf null reduziert, ist der einzige, der einen Weckruf auslöst; spätere Aufrufe sehen einen Zählstand <= 0 und kehren zurück. `io_uring_cancel_generic()` wechselt jedoch erst viel später in den Zustand `TASK_INTERRUPTIBLE`, sodass der eine Weckruf möglicherweise an einer bereits laufenden Aufgabe verschwendet wird. Das ist solange unbedenklich, wie das Eintrag des entsprechenden Aufrufs noch in der Warteschlange steht, da die Prüfung `io_local_work_pending()` dann den Schlafzustand überspringt. Dies gilt nicht, wenn der Aufruf nach dem Einstellen seines Eintrags verzögert wurde:
CPU0 (Absender im exec- oder exit-Kontext) CPU1 (`io_req_local_work_add`) mpscq_push(req A) `io_uring_try_cancel_requests()` `io_run_local_work()` // führt req A aus `io_uring_try_cancel_requests()` `atomic_set(&ctx->cq_wait_nr, 1)` `atomic_read(&ctx->cq_wait_nr) == 1` Zähler übernommen, `wake_up_state()` // Aufgabe ist bereits ausgeführt (No-Op) `prepare_to_wait(TASK_INTERRUPTIBLE)` `io_local_work_pending() == false` `scheduled()` mpscq_push(req B) `cq_wait_nr <= 0`, Rückgabe
Nur die schlafende Aufgabe kann req B ausführen, sodass sie in `execve()` blockiert bleibt, bis ein Signal sie aufweckt. Eine beendete Aufgabe erhält nicht einmal diesen Weckruf.
Aktivieren Sie den Zähler erneut, sobald der Aufgabenzustand festgelegt ist und bevor die Work-Liste überprüft wird, für die Ringe, bei denen diese Aufgabe für die Ausführung des lokalen Works zuständig ist.
VulDB is the best source for vulnerability data and more expert information about this specific topic.