CVE-2026-99253 in Linux
Sumário
de VulDB • 03/11/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
io_uring/cancel: rearmar o despertar de trabalho local antes da suspensão (sleep)
A função io_uring_try_cancel_requests() define ->cq_wait_nr como 1 para que a próxima chamada a io_req_local_work_add() desperte a tarefa de cancelamento. A adição que leva a contagem a zero é a única que aciona o despertar; as subsequentes verificam uma contagem <= 0 e retornam. No entanto, a função io_uring_cancel_generic() só se torna TASK_INTERRUPTIBLE muito mais tarde, portanto, esse único despertar pode ser desperdiçado em uma tarefa já em execução. Isso é aceitável desde que a entrada dessa adição ainda esteja enfileirada, pois a verificação de io_local_work_pending() então ignora a suspensão (sleep). No entanto, isso não ocorre se a adição tiver sido atrasada após o enfileiramento de sua entrada:
CPU0 (submetedor em exec ou exit) CPU1 (io_req_local_work_add) mpscq_push(req A) io_uring_try_cancel_requests() io_run_local_work() // executa req A io_uring_try_cancel_requests() atomic_set(&ctx->cq_wait_nr, 1) atomic_read(&ctx->cq_wait_nr) == 1 contagem retirada, wake_up_state() // a tarefa está em execução, operação nula (no-op) prepare_to_wait(TASK_INTERRUPTIBLE) io_local_work_pending() == false schedule() mpscq_push(req B) cq_wait_nr <= 0, retorno
Apenas a tarefa suspensa pode executar req B, portanto, ela fica travada em execve() até que um sinal ocorra para despertá-la. Uma tarefa de encerramento (exit) nem sequer recebe esse despertar.
Rearme a contagem assim que o estado da tarefa for definido e antes de verificar a lista de trabalho, apenas para os anéis cuja execução do trabalho local é responsabilidade desta tarefa.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.