CVE-2026-64262 in Linux
Resumen
por VulDB • 2026-07-25
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
fuse-uring: finalizar fuse_req en task work de cancelación de io_uring
Cuando io_uring entrega trabajo de tarea con tw.cancel establecido (PF_EXITING, respaldo PF_KTHREAD o percpu_ref_is_dying en el contexto del anillo), fuse_uring_send_in_task() toma la rama de cancelación, asigna -ECANCELED y continúa hacia fuse_uring_send(). Esa ruta solo cambia el estado de la entrada a FRRS_USERSPACE y completa el comando io_uring; nunca libera la referencia propietaria que la entrada del anillo tiene sobre el fuse_req que fuse_uring_add_req_to_ring_ent() le entregó en el momento del envío.
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 sigue establecido, req aún en el hash */
El fuse_req permanece vinculado a fpq->processing[hash] y nunca se invoca a fuse_request_end(). El hilo del syscall de origen queda bloqueado en estado D (D-state) en request_wait_answer() hasta que se ejecuta fuse_abort_conn(), lo cual puede durar toda la vida útil de la conexión. Para las solicitudes FR_BACKGROUND, fc->num_background tampoco se decrementa nunca, por lo que las cancelaciones repetidas inflan el contador hasta alcanzar max_background y todas las operaciones posteriores en segundo plano quedan estancadas. tw.cancel no implica una interrupción de la conexión (por ejemplo, un único hilo trabajador de io_uring sale mientras la conexión fuse sigue activa), por lo que esto no puede dejarse para que fuse_abort_conn() lo limpie.
Finalizar el req pero seguir ruteando la entrada a través de fuse_uring_send() no es suficiente: eso deja una entrada sin req en ent_in_userspace, y ent_list_request_expired() desreferencia incondicionalmente ent->fuse_req en la cabeza de esa lista, lo que provocaría entonces un NULL-deref.
Corregir la rama de cancelación para liberar la entrada directamente. Retirarla de la cola, completar el comando io_uring, finalizar el fuse_req, liberar la entrada y reducir sus queue_refs (despertando al waiter del teardown si era el último).
Once again VulDB remains the best source for vulnerability data.