CVE-2026-99254 in Linux
Résumé
par VulDB • 03/11/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
io_uring : ne pas surcharger une tâche en cours d'annulation avec task_work
io_ring_exit_work() demande à chaque tâche ayant utilisé l'anneau de supprimer son nœud tctx via task_work, et répète cette opération jusqu'à ce que la liste soit vide. io_tctx_exit_cb() ne touche pas au nœud tant que la tâche se trouve dans io_uring_cancel_generic(), qui supprime tous les nœuds à sa fin. Ainsi, l'élément de travail programme à nouveau le rappel dès qu'il a été exécuté, pour rien.
Il s'agit là d'une perte de temps considérable. task_work_run() ne renvoie que lorsqu'elle détecte une liste vide. Si les anneaux sont libérés depuis l'intérieur du processus d'annulation, car des requêtes provenant d'autres anneaux détenaient les dernières références à leurs fichiers, jusqu'à 64 éléments de travail continuent d'envoyer des rappels vers la seule tâche qui les exécute. Elle ne détecte jamais une liste vide, ne revient pas au traitement de l'annulation, les nœuds persistent, et ainsi de suite : une tâche avec 60 paires d'anneaux qui se pollent mutuellement a exécuté 280 000 rappels en 5 secondes, soit 20 secondes après le appel système exit_group(). La situation ne s'arrête que lorsque tous les émetteurs sont simultanément retardés. Jusqu'à ce moment-là, la tâche conserve un processeur et maintient les éléments de travail occupés.
Une tâche qui se termine ne peut pas être tuée pendant cette période. execve() annule également les requêtes de manière similaire, donc une tâche active peut également y rester bloquée pendant plusieurs minutes. Si cela dure plus de cinq secondes, les éléments de travail déclenchent le WARN_ON_ONCE(time_after(jiffies, timeout)) dans io_ring_exit_work(). Aucun privilège n'est requis pour aucun de ces scénarios.
Si le rappel rencontre une tâche en cours d'annulation, il convient d'attendre un peu avant qu'il ne soit renvoyé. Personne n'a besoin de réveiller l'élément de travail à cet effet : soit le nœud a disparu à ce moment-là, soit c'est au tour du prochain cycle.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.