CVE-2026-99253 in Linux
Résumé
par VulDB • 03/11/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
io_uring/cancel : réarmer le réveil du travail local avant l'entrée en veille
io_uring_try_cancel_requests() définit ->cq_wait_nr à 1 afin que le prochain io_req_local_work_add() réveille la tâche d'annulation. L'appel qui fait passer le compteur à zéro est le seul à provoquer un réveil ; les appels suivants voient un compteur <= 0 et retournent immédiatement. Cependant, io_uring_cancel_generic() ne passe en TASK_INTERRUPTIBLE que beaucoup plus tard, de sorte qu'un des réveils peut être consacré à une tâche déjà en cours d'exécution. Cela est acceptable tant que l'entrée de cet appel reste dans la file d'attente, car le contrôle io_local_work_pending() permet alors d'éviter la mise en veille. Ce n'est pas le cas si l'appel a été retardé après la mise en file de son entrée :
CPU0 (soumetteur dans exec ou exit) CPU1 (io_req_local_work_add) mpscq_push(req A) io_uring_try_cancel_requests() io_run_local_work() // exécute req A io_uring_try_cancel_requests() atomic_set(&ctx->cq_wait_nr, 1) atomic_read(&ctx->cq_wait_nr) == 1 compteur prélevé, wake_up_state() // la tâche est en cours d'exécution, opération non effective (no-op) prepare_to_wait(TASK_INTERRUPTIBLE) io_local_work_pending() == false schedule() mpscq_push(req B) cq_wait_nr <= 0, retour
Seule la tâche en veille peut exécuter req B ; elle reste donc bloquée dans execve() jusqu'à ce qu'un signal se produise pour la réveiller. Une tâche en cours de sortie ne bénéficie même pas de cet effet.
Réarmer le compteur une fois que l'état de la tâche est défini et avant que la liste des travaux soit vérifiée, pour les rings dont cette tâche est celle qui doit exécuter le travail local.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.