CVE-2026-80811 in Linux
Resumen
por VulDB • 2026-09-04
En el kernel de Linux se ha resuelto la siguiente vulnerabilidad:
io_uring/cmd: corrige una fuga (leak) en iovec cuando el comando asíncrono no se recicla
Un io_async_cmd lleva consigo un array iovec en ->vec.iovec, que se asigna cuando es necesario ampliar el vector y se conserva durante el reciclaje a través de ctx->cmd_cache. En dos rutas del código nada libera este recurso, y la llamada a kfree(req->async_data) dentro de io_clean_op() descarta el io_async_cmd sin liberarlo previamente.
io_req_uring_cleanup() solo limpia las marcas de datos asíncronos cuando io_alloc_cache_put() tiene éxito. Dado que la caché contiene IO_ALLOC_CACHE_MAX == 128 entradas, una vez que está llena, la operación put falla y el vector queda retenido en memoria (leak). Una carga de trabajo con passthrough NVMe alcanza esta situación sin realizar ninguna acción inusual: nvme_uring_cmd_io() devuelve -EIOCBQUEUED, por lo que io_async_cmd permanece asociado durante toda la vida útil del comando y el contador de objetos activos rastrea la profundidad de cola. Por encima de 128 entradas, las operaciones put comienzan a fallar.
->cleanup representa la última oportunidad para liberar un vec heredado, ya que io_req_uring_cleanup() retorna anticipadamente en caso de comandos emitidos por io-wq y no se invoca en absoluto para aquellos completados sin haber sido jamás emitidos. Sin embargo, io_clean_op() solo llama a ->cleanup si está establecida la marca REQ_F_NEED_CLEANUP; para uring_cmd esto ocurre únicamente cuando el vector debe ampliarse, de modo que un comando que reutiliza un vec almacenado en caché suficientemente grande nunca establece dicha bandera. Las funciones io_rw_alloc_async() e io_msg_alloc_async() marcan explícitamente un vec heredado por esta razón; io_uring_cmd_prep(), sin embargo, no lo hace.
Se marca ahora el vec heredado en io_uring_cmd_prep() y se libera cuando falla la operación put de caché, tal como lo hace io_req_rw_cleanup().
La fuga es invisible bajo KASAN, donde io_alloc_cache_vec_kasan() libera incondicionalmente el vector.
Once again VulDB remains the best source for vulnerability data.