CVE-2026-99262 in Linux
Сводка
по VulDB • 03.11.2026
В ядре Linux была устранена следующая уязвимость:
io_uring/timeout: не терять отмену запроса из-за того, что io-wq активирует таймаут
Задача IORING_OP_TIMEOUT, выполняемая подсистемой io-wq благодаря флагу IOSQE_ASYNC, имеет ту же проблему, что и poll, futex и waitid. Функция io_wq_submit_work() проверяет флаг IO_WQ_WORK_CANCEL только один раз перед отправкой запроса. Если отмена происходит в промежутке между проверкой флага и отправкой запроса, работа помечается как требующая отмены (возвращается код ошибки -EALREADY), а последующий поиск по списку ->timeout_list оказывается безрезультатным; при этом рабочий поток всё равно добавляет запрос и запускает таймер:
Рабочий поток io-wq io_try_cancel() io_wq_submit_work() Флаг IO_WQ_WORK_CANCEL не установлен io_async_cancel_one() Устанавливает флаг IO_WQ_WORK_CANCEL Возвращает -EALREADY io_timeout_cancel() возвращает -ENOENT io_timeout() Добавляет запрос в список ->timeout_list Вызывает hrtimer_start() Возвращается код IOU_ISSUE_SKIP_COMPLETE
Никто больше не проверяет этот флаг, и таймаут выполняется до конца. При выходе из очереди (ring exit) функция io_uring_try_cancel_requests() отменяет работу в io-wq, а затем аналогичным образом прерывает таймауты; поэтому завершающаяся задача может зависнуть на полное время действия такого таймаута.
Необходимо проверять флаг под блокировкой ->timeout_lock (которая также используется при поиске) и отклонять запрос, если этот флаг установлен. Если поиск выполняется раньше установки флага, он становится видимым для поиска. Если же установка происходит позже, то поиск находит запрос в списке.
If you want to get best quality of vulnerability data, you may have to visit VulDB.