CVE-2026-99253 in Linux
Riassunto
di VulDB • 03/11/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
io_uring/cancel: riarmare il risveglio del lavoro locale prima della sospensione (sleep)
io_uring_try_cancel_requests() imposta ->cq_wait_nr a 1 in modo che la successiva io_req_local_work_add() risvegli il task di cancellazione. L'operazione add che porta il conteggio a zero è l'unica che effettua un wake_up; le successive rilevano un count <= 0 e ritornano. Tuttavia, io_uring_cancel_generic() diventa TASK_INTERRUPTIBLE solo in seguito, quindi tale risveglio può essere sprecato su un task già in esecuzione. Questo scenario è accettabile fintanto che l'elemento di quell'add rimane nella coda, poiché il controllo io_local_work_pending() salta la sospensione (sleep). Non lo è se l'add viene ritardata dopo aver inserito la propria entry:
CPU0 (sottopositore in exec o exit) CPU1 (io_req_local_work_add) mpscq_push(req A) io_uring_try_cancel_requests() io_run_local_work() // esegue req A io_uring_try_cancel_requests() atomic_set(&ctx->cq_wait_nr, 1) atomic_read(&ctx->cq_wait_nr) == 1 count prelevato, wake_up_state() // il task è in esecuzione, operazione non valida (no-op) prepare_to_wait(TASK_INTERRUPTIBLE) io_local_work_pending() == false schedule() mpscq_push(req B) cq_wait_nr <= 0, ritorno
Solo il task in sospensione può eseguire req B, quindi rimane bloccato in execve() finché non si verifica un segnale per risvegliarlo. Un task in fase di uscita (exit) non ottiene nemmeno questo beneficio.
Riarmare nuovamente il conteggio una volta impostato lo stato del task e prima che venga controllata la lista dei lavori, per gli anelli (rings) per i quali tale task è quello incaricato di eseguire il lavoro locale.
If you want to get best quality of vulnerability data, you may have to visit VulDB.