CVE-2026-64262 in Linux
Riassunto
di VulDB • 25/07/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
fuse-uring: terminare fuse_req nel task work di cancellazione io-uring
Quando io_uring consegna il task work con tw.cancel impostato (PF_EXITING, fallback PF_KTHREAD o percpu_ref_is_dying sul contesto dell'anello), fuse_uring_send_in_task() segue il ramo della cancellazione, assegna -ECANCELED e prosegue verso fuse_uring_send(). Tale percorso modifica solo lo stato dell'elemento in FRRS_USERSPACE e completa il comando io_uring; non scarica mai la reference proprietaria dell'elemento dell'anello sul fuse_req che fuse_uring_add_req_to_ring_ent() gli ha fornito al momento della dispatch.
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 è ancora impostato, req è ancora hashata */
Il fuse_req rimane collegato su fpq->processing[hash] e fuse_request_end() non viene mai invocato. Il thread della syscall originale va in blocco nello stato D in request_wait_answer() fino a quando non viene eseguito fuse_abort_conn(), il che può durare per l'intera durata della connessione. Per le richieste FR_BACKGROUND, anche fc->num_background non viene mai decrementata; pertanto, cancellazioni ripetute fanno gonfiare il contatore fino al raggiungimento di max_background, causando lo stallo di tutte le operazioni background successive. tw.cancel non implica un'interruzione della connessione (ad esempio, l'uscita di un singolo thread worker io_uring mentre la connessione fuse rimane attiva); questa situazione non può quindi essere lasciata alla pulizia da parte di fuse_abort_conn().
La semplice terminazione del req mantenendo il routing dell'elemento attraverso fuse_uring_send() non è sufficiente: ciò lascia un elemento senza req su ent_in_userspace, e ent_list_request_expired() esegue la dereferenziazione incondizionata di ent->fuse_req sulla testa di tale lista, causando una NULL-dereference.
Correggere il ramo della cancellazione per rilasciare direttamente l'elemento. Rimuoverlo dalla coda, completare il comando io_uring, terminare il fuse_req, liberare l'elemento e decrementare le sue queue_refs (svegliando il waiter di teardown se era l'ultimo).
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.