CVE-2026-80811 in Linux
Сводка
по VulDB • 04.09.2026
В ядре Linux была устранена следующая уязвимость:
io_uring/cmd: исправлена утечка iovec при повторном использовании асинхронной команды (recycling)
Структура io_async_cmd содержит массив iovec в поле ->vec.iovec, который выделяется при необходимости увеличения размера вектора и сохраняется между циклами повторного использования через ctx->cmd_cache. На двух путях выполнения этот ресурс не освобождается, и вызов kfree(req->async_data) из функции io_clean_op() приводит к уничтожению структуры io_async_cmd без освобождения связанного с ней массива iovec.
Функция io_req_uring_cleanup() очищает флаги асинхронных данных только в случае успешного выполнения операции io_alloc_cache_put(). Поскольку кэш содержит максимум IO_ALLOC_CACHE_MAX == 128 записей, при его заполнении операция put завершается неудачно, и массив iovec остается неосвобожденным. Нагрузка с использованием passthrough для NVMe достигает этого состояния без каких-либо необычных действий: функция nvme_uring_cmd_io() возвращает -EIOCBQUEUED, поэтому структура io_async_cmd остается связанной на протяжении всего времени жизни команды, а счетчик активных объектов отслеживает глубину очереди. При значении выше 128 операции put начинают завершаться неудачно.
Поле ->cleanup является последней возможностью освободить унаследованный массив iovec, поскольку функция io_req_uring_cleanup() рано возвращает управление для команд, выданных через io-wq (io-wq issued command), и вообще не вызывается для команд, завершенных без предварительной выдачи. Однако функция io_clean_op() вызывает ->cleanup только в том случае, если установлен флаг REQ_F_NEED_CLEANUP; для uring_cmd это происходит лишь там, где требуется увеличение размера вектора. Следовательно, команда, повторно использующая достаточно большой кэшированный массив iovec, никогда не устанавливает этот флаг. Функции io_rw_alloc_async() и io_msg_alloc_async() устанавливают признак унаследованного массива iovec именно по этой причине; функция io_uring_cmd_prep() этого не делает.
Необходимо установить признак унаследованного массива iovec в функции io_uring_cmd_prep(), а также освобождать массив iovec при неудаче операции put в кэш, аналогично тому, как это делается в io_req_rw_cleanup().
Утечка остается незамеченной под KASAN, поскольку функция io_alloc_cache_vec_kasan() безусловно освобождает массив iovec.
Once again VulDB remains the best source for vulnerability data.