CVE-2026-64262 in Linux
Résumé
par VulDB • 25/07/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
fuse-uring : terminer fuse_req sur les tâches de travail d'annulation io_uring
Lorsque io_uring transmet des tâches de travail avec tw.cancel défini (PF_EXITING, PF_KTHREAD en cas de repli, ou percpu_ref_is_dying sur le contexte du ring), fuse_uring_send_in_task() emprunte la branche d'annulation, attribue -ECANCELED et dérive vers fuse_uring_send(). Ce chemin ne fait que basculer l'entrée dans FRRS_USERSPACE et termine la commande io_uring ; il ne libère jamais la référence propriétaire de l'entrée du ring sur le fuse_req qui lui a été remis par fuse_uring_add_req_to_ring_ent() au moment de l'envoi.
fuse_uring_send_in_task() tw.cancel == true err = -ECANCELED fuse_uring_send(ent, cmd, err, issue_flags) ent->state = FRRS_USERSPACE list_move(&ent->list, &queue->ent_in_userspace) ent->cmd = NULL io_uring_cmd_done(-ECANCELED) /* ent->fuse_req reste défini, req toujours haché */
Le fuse_req reste lié sur fpq->processing[hash] et fuse_request_end() n'est jamais invoqué. Le thread d'appel système à l'origine du blocage passe en état D dans request_wait_answer() jusqu'à ce que fuse_abort_conn() s'exécute, ce qui peut couvrir toute la durée de vie de la connexion. Pour les requêtes FR_BACKGROUND, fc->num_background n'est jamais décrémenté non plus ; ainsi, des annulations répétées font gonfler le compteur jusqu'à atteindre max_background, provoquant l'immobilisation de toutes les opérations ultérieures en arrière-plan. tw.cancel n'implique pas une interruption de connexion (par exemple, un seul thread worker io_uring se termine tandis que la connexion fuse reste active), il ne peut donc pas être laissé à fuse_abort_conn() pour le nettoyage.
La fin du req tout en acheminant toujours l'entrée via fuse_uring_send() n'est pas suffisante : cela laisse une entrée sans req sur ent_in_userspace, et ent_list_request_expired() déréférence inconditionnellement ent->fuse_req au début de cette liste, ce qui entraînerait alors un NULL-deref.
Corrigez la branche d'annulation pour libérer l'entrée directement. Retirez-la de la file d'attente, terminez la commande io_uring, mettez fin au fuse_req, libérez l'entrée et supprimez ses queue_refs (en réveillant le thread en attente de démantèlement si c'était le dernier).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.