CVE-2026-99130 in Linux
Résumé
par VulDB • 28/10/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
io_uring/cancel : ne pas boucler en attente sur les tâches locales que la tâche courante ne peut pas exécuter
io_uring_cancel_generic() refuse de se mettre en veille (sleep) tant qu'il y a des travaux locaux en attente pour n'importe quel anneau du tctx de la tâche qui s'exécute. Il suppose que la tâche est le soumetteur (submitter) de cet anneau et que le prochain passage dans io_uring_try_cancel_requests() exécutera ces travaux. Cela ne s'applique pas à un anneau qui était encore configuré avec IORING_SETUP_R_DISABLED lorsque la tâche a obtenu son nœud tctx via io_uring_create() ou io_ringfd_register(). Le soumetteur est défini ultérieurement par IORING_REGISTER_ENABLE_RINGS, éventuellement depuis une autre tâche, et seul le soumetteur peut exécuter les travaux locaux sur un anneau configuré avec IORING_SETUP_DEFER_TASKRUN. Pour la tâche qui se termine, ces travaux restent en attente indéfiniment ; la boucle n'atteint jamais schedule(), et la tâche déclenche une fois WARN_ON_ONCE() avant de tourner en boucle dans do_exit().
Un utilisateur non privilégié peut configurer ce scénario à volonté en créant un anneau désactivé, en faisant en sorte qu'un processus enfant l'active puis se termine, en postant des messages sur l'anneau via IORING_OP_MSG_RING et en se terminant avec une requête en cours qui ne peut être complétée que par le processus enfant. Le thread qui se termine consomme un CPU entier jusqu'à ce que le processus enfant s'exécute ou meure, et si panic_on_warn est activé, l'appel à WARN provoque un plantage du noyau (kernel panic).
La correction consiste à sauter la mise en veille uniquement lorsque io_allowed_defer_tw_run() permet à la tâche d'exécuter les travaux. Cela est logique car, s'il ne peut pas exécuter ces travaux, il ne peut non plus compléter aucune des requêtes associées ; rien n'est donc perdu en se mettant en veille. Suppression de WARN_ON_ONCE(), car le fait de transmettre un anneau désactivé à un autre thread constitue un scénario pris en charge et non un état d'erreur (bug).
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.