GRO Frag: новая LPE-уязвимость в сетевом стеке Linux позволяет получить root
В открытом доступе появился эксплоит для GRO Frag — локальной уязвимости повышения привилегий в ядре Linux, связанной с обработкой GRO и zero-copy skb в сетевом стеке. Точная дата первоначального обнаружения в публичных материалах не указана. По открытым следам можно зафиксировать две даты: исправление обсуждалось в списке рассылки netdev 20 мая 2026 года, где данная уязвимость уже описывалась как пригодная для перезаписи page cache, а публичный PoC был размещён на GitHub Gist 22 мая 2026 года.
В качестве временной меры до установки исправленного ядра можно ограничить вектор атаки через sysctl: kernel.io_uring_disabled=1. Такой режим запрещает создание новых экземпляров io_uring непривилегированными процессами, если они не включены в разрешённую группу io_uring_group; при значении группы -1 доступ сохраняется только у процессов с CAP_SYS_ADMIN. Это именно митигация, а не полноценное исправление уязвимости.
Проблема находится в функции skb_gro_receive(): при объединении пакетов GRO ядро могло переносить фрагменты из zero-copy skb в другой skb без корректной проверки состояния zero-copy и признака SKBFL_MANAGED_FRAG_REFS. В результате страницы памяти, на которые исходный skb не держал отдельные ссылки, могли быть освобождены некорректно, что приводило к use-after-free. В патче прямо указано, что такая ситуация может привести к UAF, а также что найденный вариант был пригоден для перезаписи page cache.
Опубликованный PoC описывает уязвимость как LPE через GRO managed-frag UAF с использованием io_uring SEND_ZC и виртуального сетевого интерфейса veth. В комментарии к коду указано, что затронуты ядра Linux 6.0+, эксплуатация возможна непривилегированным пользователем, но требует доступного io_uring; в качестве исправления назван коммит 4db79a322db8 с изменением «net: gro: don«t merge zcopy skbs».
По последствиям GRO Frag укладывается в тот же опасный класс ошибок, что Copy Fail и Dirty Frag: атакующий с локальным непривилегированным доступом добивается изменения данных в page cache, то есть в памяти, без обязательной модификации файла на диске. Подобные ошибки особенно неприятны тем, что затрагивают границу между «только чтением» файла и фактическим содержимым, которое видит ядро и процессы при последующих обращениях. Elastic ранее описывала этот класс как практичный путь к получению root через page-cache corruption.
На момент появления публикации отдельный CVE-идентификатор для GRO Frag, судя по доступным сообщениям, ещё не был назначен. В качестве временных мер администраторам стоит ориентироваться на обновление ядра до версии с исправлением, а также на общие меры снижения риска для подобных LPE: ограничение непривилегированных user namespaces там, где это допустимо, контроль использования io_uring и мониторинг подозрительных цепочек, связанных с локальной эскалацией привилегий. Для родственных Copy Fail/DirtyFrag-атак Elastic также рекомендует совмещать патчинг с детектированием низкоуровневых примитивов эксплуатации уязвимости.
Низкоуровневые примитивы эксплуатации — это не сам «готовый взлом», а базовые технические приёмы, из которых строится эксплоит.
В контексте GRO Frag это может означать не детектирование уже готового факта «пользователь стал root», а попытку заметить отдельные подозрительные действия, которые эксплоит использует по пути к повышению привилегий.
>>> Источник
