CVE-2026-99231 in Linux
Résumé
par VulDB • 02/11/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
io_uring/waitid : acquérir la demande avant de réinitialiser ->head
io_waitid_remove_wq() ne prend que le verrou de la file d'attente si ->head est défini. io_waitid_wait() efface en premier lieu ->head, avant d'essayer de devenir propriétaire de la demande en incrémentant ->refs. Si quelqu'un d'autre possède déjà la demande à ce stade, rien ne l'empêche de finaliser la demande pendant que le gestionnaire de réveil (wake up handler) est encore susceptible d'y accéder :
CPU0 (io_waitid_wait) CPU1 (io_waitid, détient une référence) list_del_init(&wait->entry) smp_store_release(&iw->head, NULL) __do_wait() trouve un autre enfant io_waitid_remove_wq() // ->head == NULL, pas de verrouillage io_waitid_finish(), IOU_COMPLETE // demande libérée et réutilisée atomic_fetch_inc(&iw->refs)
Il en va de même pour __io_waitid_cancel() s'il revendique la demande dans cette fenêtre. ->refs fait partie des données par opcode de la demande, donc cela incrémente n'importe quelle valeur que le prochain utilisateur de la demande y conserve. Si celle-ci est zéro, le gestionnaire conclut qu'il possède la demande et enfile io_waitid_cb() pour elle. Avec une fenêtre maintenue ouverte par un délai, et la demande réutilisée pour une réception attendant des données :
BUG: KASAN: slab-use-after-free in __wake_up_common+0x1ca/0x1f0 __wake_up_sync_key+0x36/0x50 sock_def_readable+0xf1/0x420 unix_stream_sendmsg+0x60b/0x1110 Alloué par la tâche 87 : io_arm_apoll+0x1ed/0x940 Libéré par la tâche 87 : __io_submit_flush_completions+0x118d/0x1a10 tctx_task_work_run+0x327/0x950
Ne réinitialisez ->head qu'une fois que le gestionnaire possède la demande. Sinon, le propriétaire trouve ->head défini et doit attendre le verrou, qui est détenu par l'appelant du gestionnaire. Supprimer à nouveau une entrée déjà supprimée est inoffensif.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.