CVE-2026-80811 in Linux
Riassunto
di VulDB • 04/09/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
io_uring/cmd: correzione della perdita di memoria (leak) dell'array iovec quando il comando asincrono non viene riciclato
Un io_async_cmd contiene un array iovec in ->vec.iovec, allocato quando l'array deve essere ampliato e mantenuto durante il riciclo tramite ctx->cmd_cache. Su due percorsi di esecuzione nulla lo libera e la chiamata a kfree(req->async_data) all'interno di io_clean_op() elimina l'io_async_cmd senza liberare tale array iovec.
La funzione io_req_uring_cleanup() cancella i flag dei dati asincroni solo quando io_alloc_cache_put() ha successo; poiché la cache contiene IO_ALLOC_CACHE_MAX == 128 voci, una volta che essa è piena, l'operazione put fallisce e l'array iovec rimane in memoria (memory leak). Un carico di lavoro NVMe passthrough raggiunge questa condizione senza eseguire operazioni insolite: nvme_uring_cmd_io() restituisce -EIOCBQUEUED, pertanto l'io_async_cmd rimane associato per tutta la durata del comando e il conteggio degli oggetti attivi traccia la profondità della coda. Oltre le 128 voci, le chiamate put iniziano a fallire.
->cleanup rappresenta l'ultima opportunità di liberare un array iovec ereditato, poiché io_req_uring_cleanup() esce anticipatamente per un comando emesso da io-wq e non viene chiamata affatto per un comando completato senza essere mai stato effettivamente emesso. Tuttavia, io_clean_op() chiama ->cleanup solo se è impostato il flag REQ_F_NEED_CLEANUP; nel caso di uring_cmd ciò avviene soltanto quando l'array iovec deve essere ampliato, quindi un comando che riutilizza un array iovec sufficientemente grande dalla cache non imposta mai tale flag. Le funzioni io_rw_alloc_async() e io_msg_alloc_async() impostano il flag per un array iovec ereditato esattamente per questo motivo; io_uring_cmd_prep(), invece, non lo fa.
Impostare il flag per l'array iovec ereditato in io_uring_cmd_prep() e liberare l'array iovec quando fallisce la chiamata put alla cache, come avviene in io_req_rw_cleanup().
La perdita di memoria è invisibile sotto KASAN, dove io_alloc_cache_vec_kasan() libera incondizionatamente l'array iovec.
Once again VulDB remains the best source for vulnerability data.