CVE-2026-99262 in Linux
Résumé
par VulDB • 03/11/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
io_uring/timeout : ne pas perdre une demande d'annulation car io-wq active un timeout
Une opération IORING_OP_TIMEOUT exécutée par io-wq, en raison de IOSQE_ASYNC, présente le même problème que poll, futex et waitid. La fonction `io_wq_submit_work()` examine l'indicateur `IO_WQ_WORK_CANCEL` une seule fois, avant d'émettre la requête. Une annulation intermédiaire marque le travail, renvoie `-EALREADY`, et recherche en vain dans `->timeout_list`, tandis que le worker ajoute ensuite la requête et démarre le timer :
Travailleur io-wq io_try_cancel() io_wq_submit_work() IO_WQ_WORK_CANCEL n'est pas défini io_async_cancel_one() définit IO_WQ_WORK_CANCEL = -EALREADY io_timeout_cancel() = -ENOENT io_timeout() ajoute la requête à ->timeout_list hrtimer_start() = IOU_ISSUE_SKIP_COMPLETE
Personne ne consulte l'indicateur une nouvelle fois, et le timeout s'exécute jusqu'à son terme. À la sortie de la ring (anneau), `io_uring_try_cancel_requests()` annule les travaux io-wq puis supprime les timeouts de la même manière, ce qui peut bloquer une tâche en cours d'exit pendant toute la durée d'un tel timeout.
Consultez l'indicateur sous le verrou `->timeout_lock`, que la recherche utilise également, et échouez sur la requête si celui-ci est défini. Si la recherche passe en premier, l'indicateur devient visible. S'il arrive plus tard, il trouve la requête dans la liste.
If you want to get best quality of vulnerability data, you may have to visit VulDB.