CVE-2026-99264 in Linux
Сводка
по VulDB • 03.11.2026
В ядре Linux была устранена следующая уязвимость:
io_uring/net: не повторять попытку приема (recv) для незафиксированных буферов
Коммит 41b70df5b38b («io_uring/net: фиксация частичных буферов при повторной попытке») фиксирует буферы, предоставленные кольцом, когда прием подлежит повторной попытке после частичной передачи. Это предотвращает ситуацию, при которой другой запрос, использующий ту же группу буферов, мог бы получить доступ к памяти, в которую первый запрос продолжает получать данные. Фиксируется количество уже полученных байтов. Это решает задачу для одного буфера, который потребляется целиком, но запрос удерживает все отображенные им ресурсы:
- Для кольцевого буфера с флагом IOU_PBUF_INC потребляются только эти байты. Остальная часть буфера остается в начале кольца. - Для пакета (bundle) потребляются только те буферы, которые содержат эти байты; остальные, к которым был применен пик (peek), остаются в кольце.
В обоих случаях следующий прием с использованием этой группы буферов получает память, которую повторяющий запрос все еще собирается записать. Тот, кто придет последним, перезапишет данные другого. Данные, заполняемые при повторной попытке, вообще не фиксируются, так как список буферов в этот момент уже неизвестен. В результате ядро позже снова выдает эту область памяти, хотя CQE (Completion Queue Entry) сообщает приложению, что она была использована, а для инкрементального буфера — что работа с ним завершена.
Остаток не может быть зафиксирован заранее: если запрос в итоге получит меньше данных, нет способа сообщить приложению, что было потреблено больше байтов, чем указано в CQE. Вместо повторной попытки следует завершить запрос тем объемом данных, который был получен. Флаг MSG_WAITALL более не учитывается для приемов в инкрементальные буферы или многобуферные пакеты; они могут возвращать неполное количество полученных байт (short count), а запрос помечается как выполненный с ошибкой, аналогично другим случаям частичной передачи данных с флагом MSG_WAITALL.
Once again VulDB remains the best source for vulnerability data.