За сутки в списке рассылки linux-cve-announce появилось 432 отчёта об уязвимостях ядра Linux, и каждому присвоен отдельный CVE-идентификатор. Всплеск вызван не волной атак, а разбором накопившейся очереди: сопровождающий стабильные ветки ядра Грег Кроа-Хартман выпустил сотни отложенных записей одним пакетом. Среди них выделяется Frag Gap – локальная уязвимость с рабочим эксплойтом, дающим непривилегированному пользователю права root. По оценке Кроа-Хартмана, поток находок, ускоренный ИИ-инструментами, будет только расти в ближайшие полтора года.
432 отчёта об уязвимостях за сутки
Записи появились в официальном списке рассылки linux-cve-announce –: основная часть пришлась на 19 июля, ещё несколько сообщений – на следующий день. Все 432 записи – это отдельные CVE-идентификаторы, присвоенные исправлениям ошибок в ядре, от сетевого стека и подсистемы памяти до драйверов Wi-Fi и файловых систем.
Разовая публикация такого объёма вызвала обсуждение в списке рассылки oss-security. Один из участников поставил вопрос прямо: при потоке в сотни CVE за сутки вручную приоритизировать отдельные изменения ядра стало физически невозможно, а привычная модель, при которой организация реагирует лишь на уязвимости с громким названием, перестаёт работать.
Почему сотни CVE вышли одним пакетом
Кроа-Хартман, отвечающий за стабильную и staging-ветки ядра, пояснил, что дело не во внезапной волне атак, а в накопившейся очереди ревью. Из-за шести недель конференций и отпусков разбор отложенных сообщений задержался, а на выходных очередь удалось разгрести и выпустить одним пакетом. Все эти CVE неделями ждали публикации, а сам процесс их рассмотрения ведётся открыто в git-репозитории проекта.
Программное обеспечение никогда не проектировалось под идеальную безопасность, и сегодня этот выбор нас настигает.
– замечание ИБ-исследователя, приведённое Кроа-Хартманом в переписке
Поток уязвимостей от ИИ и что делать администраторам
По оценке Кроа-Хартмана, число уязвимостей, найденных с помощью больших языковых моделей, сейчас только растёт, и разбираться с этим потоком придётся как минимум ближайшие полтора года. Отслеживать каждую проблему по отдельности при таком темпе команде ядра не по силам, поэтому он советует не гнаться за отдельными CVE, а положиться на команды, сопровождающие дистрибутивы, и своевременно устанавливать все выходящие обновления.
Для тех, кто всё же хочет фильтровать поток, Кроа-Хартман описал автоматизированный подход: если пересечь список файлов, затронутых каждой CVE, с файлами, которые реально собираются в конкретном ядре, значимой остаётся примерно десятая часть записей. Именно так, по его словам, поступают корпоративные дистрибутивы для своих клиентов. Стратегию точечных обновлений «в режиме паники», когда исправление ставят только под давлением громкой новости, он назвал уходящей в прошлое – в том числе из-за требований регуляторов.
CVE как обязанность: статус CNA и Закон ЕС о киберустойчивости
Столь высокая частота присвоения CVE связана с тем, что с февраля 2024 года проект ядра сам выступает центром нумерации CVE для своих уязвимостей. Команда назначает идентификатор практически любому исправлению ошибки, потенциально затрагивающему безопасность, из соображений осторожности: на уровне ядра почти любой баг теоретически пригоден для атаки, а очевидность этого на момент исправления часто отсутствует. Отсюда и цифры, кратно превышающие показатели других производителей.
CNA (CVE Numbering Authority) – организация, уполномоченная присваивать CVE-идентификаторы уязвимостям в своей зоне ответственности. Ядро Linux получило этот статус в феврале 2024 года и с тех пор нумерует собственные уязвимости самостоятельно, без посредников.
Отсылка Кроа-Хартмана к требованиям регуляторов касается прежде всего Закона ЕС о киберустойчивости (Cyber Resilience Act). Обязанность производителей сообщать об активно эксплуатируемых уязвимостях и серьёзных инцидентах вступает в силу , а в полном объёме регламент начинает применяться . Для производителей устройств с цифровыми компонентами это означает, что игнорировать поток исправлений ядра станет не только рискованно, но и незаконно.
Frag Gap: рабочий эксплойт среди четырёх сотен уязвимостей
Из общей массы выделяется Frag Gap (в оригинальном разборе – Fraggap) – единственная в этой партии уязвимость с готовым рабочим эксплойтом. Она существует в двух вариантах: CVE-2026-53362 для стека IPv6 и CVE-2026-53366 для IPv4. Оба идентификатора относятся к одной ошибке учёта памяти в коде объединения UDP-пакетов. Эксплойт был собран в рамках соревнования kernelCTF и опубликован вместе с техническим разбором; он позволяет непривилегированному локальному пользователю получить в системе права root.
Уязвимость срабатывает при отправке через UDP-сокет порции данных, размер которой превышает допустимый размер фрагмента (MTU), с выставленной опцией UDP_CORK – она предписывает ядру объединять поступающие данные в одну датаграмму. На пути постраничного выделения памяти с флагом MSG_SPLICE_PAGES, который выставляется при передаче данных из канала (pipe) в сокет вызовом splice(), перенесённые из предыдущего сетевого буфера байты учитываются дважды и с противоположными знаками.
Из-за ошибки под линейную область не резервируется место, и 15 хвостовых байтов записываются за пределами выделенного буфера – прямо в идущую следом служебную структуру skb_shared_info. Достаточно изменить в ней единственное поле nr_frags, задающее число фрагментов, чтобы ядро начало считать оставшийся на куче адрес страницы выделенным фрагментом. Дальнейшая цепочка приводит к преждевременному освобождению страницы (use-after-free), её повторному использованию под таблицу страниц и, в конечном счёте, к перезаписи параметра core_pattern, через который запускается процесс с правами root.
skb_shared_info – служебная структура в конце каждого сетевого буфера ядра (sk_buff). Она хранит метаданные о фрагментах пакета, в том числе поле nr_frags с их числом. Запись за границу буфера позволяет подменить эти метаданные, не трогая сам пакет.
Для атаки через IPv6 достаточно, чтобы ядро было собрано с параметром CONFIG_IPV6=y – это конфигурация по умолчанию в большинстве дистрибутивов. Для варианта через IPv4 дополнительно нужна возможность создавать пространства имён пользователей (user namespace).
Затронутые версии ядра и корректирующие выпуски
Ошибочный учёт памяти появился в ядре с коммитом 773ba4fe9104 в июле 2022 года, а пригодным для эксплуатации через MSG_SPLICE_PAGES стал после изменения ce650a166335 в августе 2023 года. По данным карточки CVE, уязвимыми считаются ядра начиная с ветки 6.0. Исправление для IPv6 (коммит 736b380e28d0) попало в основную ветку ; заплатка для IPv4 (коммит eca856950f7c) устраняет тот же дефект в соседней функции. Правки восстанавливают нарушенный баланс: прибавляют реально копируемые байты к размеру линейного участка и вычитают их из постраничной части.
Ниже – минимальные версии по веткам, в которых закрыты обе уязвимости.
| Ветка ядра | Выпуск с исправлением IPv6 | Выпуск с исправлением IPv4 |
|---|---|---|
| 7.1.x | 7.1.3 | 7.1.3 |
| 6.18.x | 6.18.38 | 6.18.38 |
| 6.12.x | 6.12.95 | 6.12.95 |
| 6.6.x | 6.6.144 | 6.6.144 |
| 6.1.x | 6.1.177 | 6.1.178 |
Проверить статус устранения в конкретном дистрибутиве можно на страницах отслеживания безопасности Debian, Ubuntu, SUSE/openSUSE, RHEL, Gentoo, Arch и Fedora по идентификатору CVE-2026-53362.
Заключение
Разовый выброс 432 CVE показывает главное изменение: инструменты автоматического поиска ошибок резко нарастили число выявляемых уязвимостей, а формальная отчётность по ним из добровольной практики превращается в обязанность. Отдельные записи в этом потоке различаются по опасности радикально – от малозначимых до Frag Gap с готовым эксплойтом на root, – но вручную отделить одно от другого при таком темпе уже нереально.
Практический вывод для администраторов не изменился: надёжнее регулярно обновлять ядро из стабильной или LTS-ветки, чем выбирать отдельные заплатки. Frag Gap, к примеру, закрыт в выпусках 7.1.3, 6.18.38, 6.12.95, 6.6.144 и 6.1.178, и установка любого из них с последующей перезагрузкой снимает обе уязвимости. Frag Gap продолжает серию проблем повышения привилегий в Linux, раскрытых с начала года: ранее исследователи сообщали о Copy Fail, Dirty Frag, Fragnesia, DirtyDecrypt/DirtyCBC и RefluXFS. О выходе ядра на первое место по числу присвоенных CVE за первое полугодие 2026 года мы рассказывали отдельно.