CVE-2026-80811 in Linux
Zusammenfassung
von VulDB • 04.09.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
io_uring/cmd: Behebung eines iovec-Lecks, wenn der asynchrone Befehl nicht wiederverwendet wird
Ein io_async_cmd enthält ein iovec-Array in ->vec.iovec, das allokiert wird, wenn die vec-Wurzel wachsen muss, und über den Recycling-Prozess hinweg durch ctx->cmd_cache beibehalten wird. Auf zwei Pfaden wird es nirgendwo freigegeben, und io_clean_op()'s kfree(req->async_data) verwirft den io_async_cmd ohne dieses Element.
io_req_uring_cleanup() löscht die asynchronen Datenflags nur dann, wenn io_alloc_cache_put() erfolgreich ist, und der Cache hält IO_ALLOC_CACHE_MAX == 128 Einträge; sobald dieser voll ist, schlägt das „Put" fehl und die vec bleibt zurück. Eine NVMe-Passthrough-Arbeitslast erreicht diesen Zustand ohne etwas Ungewöhnliches zu tun: nvme_uring_cmd_io() gibt -EIOCBQUEUED zurück, sodass der io_async_cmd für die Lebensdauer des Befehls angehängt bleibt und die Live-Objektanzahl die Warteschlangentiefe verfolgt. Ab 128 beginnen die „Put"-Vorgänge zu fehlschlagen.
->cleanup ist die letzte Gelegenheit, eine vererbte vec freizugeben, da io_req_uring_cleanup() bei einem über io-wq ausgeführten Befehl frühzeitig zurückkehrt und für einen ohne jemals ausgeführt wordenen Abschluss überhaupt nicht aufgerufen wird. Aber io_clean_op() ruft ->cleanup nur dann auf, wenn REQ_F_NEED_CLEANUP gesetzt ist, und dies tritt bei uring_cmd nur dort ein, wo die vec wachsen muss; daher setzt ein Befehl, der eine ausreichend große zwischengespeicherte vec wiederverwendet, dieses Flag nie. io_rw_alloc_async() und io_msg_alloc_async() markieren eine vererbte vec genau aus diesem Grund; io_uring_cmd_prep() tut dies nicht.
Markiere eine vererbte vec in io_uring_cmd_prep(), und gib die vec frei, wenn das Cache-Put fehlschlägt, wie es io_req_rw_cleanup() macht.
Das Leck ist unter KASAN unsichtbar, wo io_alloc_cache_vec_kasan() die vec bedingungslos freigibt.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.