CVE-2026-99253 Pérdida de despertar de trabajo local en cancelación de io_uring
En el kernel Linux, io_uring_cancel_generic() puede consumir el único despertar de cq_wait_nr antes de pasar a TASK_INTERRUPTIBLE, dejando la cancelación dormida. La corrección rearma el despertar de trabajo local antes de dormir.
CVSS 3.1 · PRELIMINAR
- Probabilidad de explotación · EPSS del 09/110,2 % · percentil 8
- Explotada activamenteNo confirmada
- Exploit públicoNo conocido
Afectados
Linux
desde d46ab2c98ababa19b41a5709b6921d7b1add7f74 hasta antes de aaa06bb9fc03384f7cf2dbc3e43f2939cc7791b2desde d46ab2c98ababa19b41a5709b6921d7b1add7f74 hasta antes de 58ddf0ec707093206a5fe814581ec5aefac8b08adesde d46ab2c98ababa19b41a5709b6921d7b1add7f74 hasta antes de 76a82c666abf155ad52d5f41043eac77dd3e41d8
Linux
7.2
Qué hacer
- Verificá si usás Linux y en qué versión.
- Actualizá a la versión corregida que indique el fabricante en su aviso o aplicá su mitigación.
- Revisá registros y accesos de los sistemas expuestos para descartar un uso previo.
Calculadora CVSS
Esta vulnerabilidad todavía no tiene vector CVSS publicado.
Descripción original
In the Linux kernel, the following vulnerability has been resolved:
io_uring/cancel: rearm local work wake up before sleep
io_uring_try_cancel_requests() sets ->cq_wait_nr to 1 so that the next
io_req_local_work_add() wakes the cancelling task. The add that takes the
count to zero is the only one that wakes, later ones see a count <= 0 and
return. io_uring_cancel_generic() however only becomes
TASK_INTERRUPTIBLE much later, so the one wake up can be spent on a
running task. That is fine as long as the entry of that add is still
queued, as the io_local_work_pending() check then skips the sleep. It is
not if the add was delayed after queueing its entry:
CPU0 (submitter in exec or exit) CPU1 (io_req_local_work_add)
mpscq_push(req A)
io_uring_try_cancel_requests()
io_run_local_work() // runs req A
io_uring_try_cancel_requests()
atomic_set(&ctx->cq_wait_nr, 1)
atomic_read(&ctx->cq_wait_nr) == 1
count taken, wake_up_state()
// task is running, no-op
prepare_to_wait(TASK_INTERRUPTIBLE)
io_local_work_pending() == false
schedule()
mpscq_push(req B)
cq_wait_nr <= 0, return
Only the sleeping task can run req B, so it is stuck in execve() until a
signal happens to wake it. An exiting task doesn't even get that.
Arm the count again once the task state is set and before the work list
is checked, for the rings whose local work this task is the one to run.
Referencias (3)
Resumen traducido automáticamente de la descripción original. Fuente: Nureq Monitor. Cómo funciona.