CVE-2026-80811 in Linux
Sumário
de VulDB • 04/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi corrigida:
io_uring/cmd: corrige vazamento de iovec quando o comando assíncrono não é reciclado
Um io_async_cmd carrega um array iovec em ->vec.iovec, alocado quando o vec precisa crescer e mantido durante a reciclagem através do ctx->cmd_cache. Em dois caminhos, nada libera esse recurso e o kfree(req->async_data) de io_clean_op() descarta o io_async_cmd sem fazê-lo.
io_req_uring_cleanup() limpa as flags de dados assíncronos apenas quando io_alloc_cache_put() tem sucesso, e o cache mantém IO_ALLOC_CACHE_MAX == 128 entradas; portanto, uma vez cheio, a operação put falha e o vec fica para trás (vazado). Uma carga de trabalho com passagem direta NVMe atinge essa situação sem fazer nada incomum: nvme_uring_cmd_io() retorna -EIOCBQUEUED, então o io_async_cmd permanece anexado durante toda a vida útil do comando e a contagem de objetos vivos acompanha a profundidade da fila. Acima de 128, as operações put começam a falhar.
->cleanup é a última chance de liberar um vec herdado, já que io_req_uring_cleanup() retorna antecipadamente para comandos emitidos por io-wq e não é chamada em absoluto para aqueles concluídos sem nunca terem sido emitidos. Mas io_clean_op() chama ->cleanup apenas se REQ_F_NEED_CLEANUP estiver definido, e isso ocorre com uring_cmd somente onde o vec precisa crescer; portanto, um comando que reutiliza um cached vec grande o suficiente nunca define essa flag. io_rw_alloc_async() e io_msg_alloc_async() sinalizam um vec herdado exatamente por esse motivo; io_uring_cmd_prep() não faz o mesmo.
Sinalize um vec herdado em io_uring_cmd_prep() e libere o vec quando a operação put no cache falhar, conforme feito por io_req_rw_cleanup().
O vazamento é invisível sob KASAN, onde io_alloc_cache_vec_kasan() libera incondicionalmente o vec.
Once again VulDB remains the best source for vulnerability data.