Как отсутствие защиты copy-on-write нарушило модель безопасности ядра Linux

Стратегия многомиллионной защиты обычно опирается на предположение, что ядро основной операционной системы является статичным, неприступным хранилищем. Мы тратим годы на совершенствование правил брандмауэра, поставщиков удостоверений и скриптов обнаружения конечных точек, однако архитектурный фундамент часто остается наиболее хрупким компонентом. Linux использует оптимизацию под названием copy-on-write (копирование при записи) для эффективного управления памятью. Эта система гарантирует, что несколько процессов используют одну и ту же физическую память до тех пор, пока одному из них не потребуется ее изменить. В этот момент ядро должно создать частную копию, чтобы предотвратить влияние изменений на других пользователей. В случае с CVE-2026-31635 это базовое обещание не было выполнено.

Я провел последние 48 часов, изучая код доказательства концепции (PoC), выпущенный для DirtyDecrypt, также известной как DirtyCBC. Эта уязвимость является хрестоматийным примером архитектурного парадокса. Тот самый механизм, который был разработан для того, чтобы сделать ядро Linux быстрым и эффективным с точки зрения памяти, позволил непривилегированному пользователю перезаписывать файлы, принадлежащие root. Это уже третий крупный вариант конкретно этой логики повреждения памяти, который мы наблюдаем за последние три месяца. Это напоминает мне корабль, построенный с корпусом, который непроницаем снаружи, но растворяется при контакте с собственным внутренним топливом.

Механика уязвимости rxgk pagecache

Дефект кроется в функции rxgk_decrypt_skb. Этот код обрабатывает дешифрование входящих сокетных буферов на стороне приема сетевого стека. Когда ядро обрабатывает эти буферы, оно оперирует страницами памяти, которые иногда разделяются с кэшем страниц (page cache) других процессов. В нормальных условиях ядро Linux инициирует операцию copy-on-write перед любой записью в общую страницу. Это предотвращает утечку данных из одного процесса в пространство памяти другого.

Исследователи из Zellic обнаружили, что в rxgk_decrypt_skb отсутствовала эта защита COW. Когда ядро дешифрует данные в буфер, который оказывается общей страницей, оно записывает расшифрованное содержимое напрямую в физическую память без предварительного создания частной копии. Это обходит стандартные разрешения файловой системы и механизмы защиты памяти. Злоумышленник может отобразить конфиденциальный файл, такой как /etc/shadow, или SUID-бинарный файл в свое пространство памяти, а затем использовать уязвимый сетевой путь, чтобы заставить ядро записать данные в кэш страниц этого файла. Как только ядро сбросит кэш страниц на диск, изменения станут постоянными.

Прослеживание родословной от Copy Fail до DirtyDecrypt

DirtyDecrypt не является изолированным инцидентом. Это потомок семейства уязвимостей, которое началось с Copy Fail (CVE-2026-31431) в апреле 2026 года. Исследователи из Theori первыми обнаружили, что криптографический интерфейс сокетов в ядре имел аналогичные логические недостатки. Неделю спустя появилась Dirty Frag. За ней последовала Fragnesia, нацеленная на подсистему XFRM. Каждая из этих уязвимостей имеет одну и ту же первопричину: неспособность проверить принадлежность страницы перед выполнением записей на уровне ядра.

Эта последовательность раскрытий подчеркивает системную проблему в том, как ядро Linux обрабатывает современные сетевые оптимизации памяти. Внедрение MSG_SPLICE_PAGES и других высокопроизводительных механизмов zero-copy привнесло сложность, которую текущая инфраструктура COW с трудом регулирует. Исследователь, известный как 0xdeadbeefnetwork, отметил, что как только исправление для одного варианта попадает в публичное дерево, создание оружия на базе следующего варианта становится стандартным упражнением для специалистов по безопасности. Этот быстрый цикл разработки n-day эксплойтов является напоминанием о том, что патч в одной подсистеме не гарантирует безопасность другой, использующей аналогичную логику.

Почему определенные дистрибутивы остаются под прицелом

Влияние CVE-2026-31635 сильно зависит от конфигурации ядра. Уязвимость требует включения опции CONFIG_RXGK. Вот почему такие дистрибутивы, как Fedora, Arch Linux и openSUSE Tumbleweed, подвергаются более высокому риску. Эти дистрибутивы часто отдают предпочтение передовым функциям и широкой поддержке оборудования, что включает включение специализированных сетевых и криптографических модулей, которые отключены в более консервативных корпоративных выпусках, таких как RHEL или Debian Stable.

В облачных средах эта уязвимость представляет значительный риск для изоляции контейнеров. Если рабочий узел работает на уязвимом ядре, скомпрометированный контейнер может использовать примитив DirtyDecrypt для побега из своей локальной среды. Перезаписывая кэш страниц для общих бинарных файлов или структур ядра, злоумышленник может перейти из ограниченного пода к полному доступу root на хосте. Это фактически разрушает многопользовательскую модель безопасности, на которую полагаются Kubernetes и другие оркестраторы для изоляции рабочих нагрузок.

Дебаты о «киллсвитче» и будущее патчинга ядра

Объем раскрытий уязвимостей ядра заставил переосмыслить методы управления безопасностью Linux. Саша Левин, видный мейнтейнер ядра, недавно предложил «киллсвитч» (аварийный выключатель) ядра. Этот инструмент позволяет администратору отключать определенную функцию ядра во время выполнения без перезагрузки. Если в конкретной сетевой функции обнаруживается уязвимость нулевого дня, такая как DirtyDecrypt, администратор может приказать ядру прекратить выполнение этой функции и вместо этого возвращать фиксированное значение. Это действует как аварийный запорный клапан для корпуса корабля, пока готовится постоянный патч.

Некоторые разработчики обеспокоены последствиями для безопасности самого киллсвитча. Если злоумышленник получит достаточно привилегий для активации киллсвитча, он теоретически сможет отключить модули безопасности или функции аудита. Однако текущая реальность экосистемы Linux такова, что патчинг происходит слишком медленно для скорости разработки современных эксплойтов. Киллсвитч обеспечивает реактивную меру для организаций, которые не могут ждать полного регрессионного тестирования новой версии ядра. Это прагматичный ответ на тот факт, что наше программное обеспечение становится слишком сложным, чтобы быть свободным от ошибок.

Rocky Linux и переход к ускоренному выпуску исправлений безопасности

Rocky Linux применил другой подход, представив выделенный репозиторий безопасности. Традиционно нижестоящие (downstream) дистрибутивы ждут, пока вышестоящие (upstream) поставщики выпустят проверенный патч, прежде чем отправлять обновления своим пользователям. Это создает окно уязвимости, когда PoC уже публичен, но официальное обновление застряло в цикле контроля качества. Новый репозиторий безопасности Rocky Linux — это подключаемая функция, которая поставляет срочные исправления, как только они становятся доступны, даже если они еще не достигли основной ветки ядра.

Этот шаг является спорным, поскольку он нарушает строгую совместимость с upstream. Если команда Rocky Linux исправит ошибку, а мейнтейнеры upstream позже выберут другое исправление, два ядра разойдутся. Мейнтейнеры признают этот риск, но считают, что защита их пользователей важнее, чем идеальное выравнивание версий. Это отражает более широкий сдвиг в отрасли в сторону приоритета гибкости перед лицом активной эксплуатации. Для администраторов это означает выбор между стабильностью традиционного цикла выпуска и устойчивостью более агрессивной стратегии патчинга.

Смягчение рисков в контейнерных средах и на «голом железе»

Защита от CVE-2026-31635 требует большего, чем просто стандартное обновление. Организации должны сначала проверить, уязвимы ли их системы вообще. Проверка конфигурации ядра на наличие CONFIG_RXGK — это первый шаг. Если модуль включен, но не требуется для вашей рабочей нагрузки, его отключение через черный список модулей ядра является наиболее эффективным немедленным смягчением последствий. Это полностью удаляет поверхность атаки без необходимости перезагрузки в некоторых случаях.

С точки зрения рисков, следует исходить из того, что локальные пользователи имеют возможность выполнить этот PoC, если у них есть доступ к оболочке. Это делает необходимым строгий мониторинг каталога /etc/ и SUID-бинарных файлов. Современные инструменты безопасности, отслеживающие целостность кэша страниц, могут предупредить вас, если процесс пытается изменить файлы, доступные только для чтения, через нетрадиционные пути памяти. Патчинг остается золотым стандартом, но пока ваш парк систем не обновлен, ограничительные профили Seccomp и политики AppArmor могут ограничить возможность локальных процессов взаимодействовать с уязвимыми сетевыми функциями.

Проведите аудит конфигурации вашего ядра и проверьте, выпустил ли ваш дистрибутив исправление для CVE-2026-31635. Организации, использующие Arch или Fedora, должны приоритизировать эти обновления немедленно. Если вы управляете большим парком серверов Linux, рассмотрите долгосрочные последствия использования ядер с широким набором функций и оцените, подходит ли более защищенная минимальная конфигурация ядра для вашей стратегии безопасности.

Источники

• NIST National Vulnerability Database (NVD) CVE-2026-31635 Record
• Linux Kernel Mailing List (LKML) Killswitch Proposal by Sasha Levin
• Zellic and V12 Security Technical Report on DirtyDecrypt
• Rocky Linux Security Repository Documentation
• MITRE ATT&CK Framework: Exploitation for Privilege Escalation (T1068)

Отказ от ответственности: Данная статья предназначена только для информационных и образовательных целей. Она не заменяет профессиональный аудит кибербезопасности или услуги по реагированию на инциденты. Предоставленные технические детали призваны помочь администраторам понять риски и внедрить необходимые меры защиты.