CVE-2026-99252 in Linux
Résumé
par VulDB • 03/11/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
io_uring/mpscq : désactiver l'ordonnançage (préemption) lors de l'ajout au tampon
Un ajout fait du nœud la nouvelle queue, puis le lie à son prédécesseur. Entre-temps, la file d'attente n'est pas vide, mais mpscq_pop() ne peut pas accéder au nœud. Les consommateurs gèrent cette situation en réessayant, avec un appel à cond_resched() dans la boucle pour donner au producteur préempté l'occasion de terminer son opération.
cond_resched() n'affecte rien si le consommateur a une priorité supérieure à celle du producteur et que les deux doivent utiliser le même CPU :
producteur (SCHED_OTHER) consommateur (SCHED_FIFO), même CPU io_req_local_work_add() mpscq_push() prev = xchg(&q->tail, node) io_cqring_wait() __io_run_local_work() again: cond_resched() // rien à faire mpscq_pop() // NULL // travail en attente, aucun événement encore goto again
Le producteur peut être n'importe quelle tâche capable de mettre des task_work dans la file d'attente du ring : un worker io-wq, ou quelqu'un qui envoie un message avec IORING_OP_MSG_RING. Le consommateur tourne en boucle (spin), maintenant ->uring_lock, jusqu'à ce que l'ordonnanceur fasse preuve de clémence envers la classe équitable (fair class), ce qui prend environ une seconde avec les paramètres par défaut du serveur équitable, et indéfiniment sans celui-ci. Les boucles dans tctx_task_work_run() et io_cancel_local_task_work() présentent le même problème.
Ne pas autoriser l'ordonnançage entre les deux étapes. Cela borne la durée pendant laquelle cette fenêtre est ouverte sur le CPU du producteur par ce que prennent les interruptions, et un consommateur qui attend pour cela se trouve sur un autre CPU. Le coût est une paire preempt_disable()/preempt_enable() par ajout (push).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.