Dirty Frag — новая, пока не исправленная уязвимость локального повышения привилегий в ядре Linux, позволяющая любому локальному пользователю получить права root на большинстве популярных дистрибутивов (Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, Fedora 44 и др.), при этом стандартная временная защита от Copy Fail (CVE-2026-31431) не работает: опубликован рабочий proof-of-concept, эксплуатация выполняется одной командой, а до выхода патчей единственной практической мерой остаётся блокировка модулей esp4, esp6 и rxrpc.

Технические детали Dirty Frag

Исследователь Hyunwoo Kim описывает Dirty Frag как развитие того же класса логических ошибок ядра, к которому относятся уязвимости Dirty Pipe и Copy Fail (CVE-2026-31431, CVSS 7.8). Ключевая особенность класса — детерминированная логическая ошибка без гонки:

• не требуется race condition или точное попадание в тайминг;
• при неудачной попытке эксплуатации ядро не падает (нет panic);
• вероятность успешного повышения привилегий близка к 100% в подходящей конфигурации.

Dirty Frag строится на связке двух разных ошибок записи в кеш страниц ядра: xfrm-ESP Page-Cache Write и RxRPC Page-Cache Write. Обе ошибки позволяют некорректно модифицировать данные в кеш страниц, которые при этом всё ещё находятся под контролем непривилегированного процесса. Это классический сценарий эксплуатации уязвимости типа Exploit for Privilege Escalation (T1068) по MITRE ATT&CK.

xfrm-ESP Page-Cache Write: 4-байтовая примитивная запись через IPSec

Первая составляющая — уязвимость в подсистеме IPSec (xfrm), обозначенная исследователем как xfrm-ESP Page-Cache Write. Ошибка:

• возникла после коммита в январе 2017 года;
• коррелирует с тем же изменением, что стало причиной переполнения буфера CVE-2022-27666 (CVSS 7.8), описанного в NVD для CVE-2022-27666;
• даёт атакующему 4-байтовый примитив записи в кеш страниц ядра, аналогичный по мощности тому, который применялся в Copy Fail.

Эта часть эксплойта опирается на работу ESP в связке с кешем страниц: при обработке трафика IPSec (через интерфейс XFRM user netlink) ядро выполняет операции дешифрования «на месте» поверх страниц, которые могут быть поддержаны внешними объектами (например, страницами канала, присоединёнными через splice() или sendfile()). При этом возможна запись по данным, на которые всё ещё имеет ссылку непривилегированный процесс.

Критичное ограничение: для эксплуатации xfrm-ESP варианта требуется возможность создавать пользовательские пространства имён. На Ubuntu это по умолчанию блокируется профилями AppArmor, поэтому в такой конфигурации данный путь эксплуатации недоступен.

RxRPC Page-Cache Write: обход запрета на создание namespace

Вторая составляющая — RxRPC Page-Cache Write. Она появилась в ядре позже, после коммита июня 2023 года, и повторяет общий дефектный паттерн в пути дешифрования, но:

• не требует прав на создание пользовательских пространств имён;
• задействует модуль rxrpc.ko, который отсутствует в стандартной поставке многих дистрибутивов (например, RHEL 10.1), но по умолчанию загружается в Ubuntu.

С технической точки зрения ошибка аналогична: подсистема RxRPC, как и esp4/esp6, выполняет дешифрование «на месте» поверх страниц, не являющихся полностью приватными для ядра. В результате незашифрованные данные или сами структуры ядра, расположенные в этих страницах, могут быть искажены кодом непривилегированного процесса.

Цепочка эксплуатации: взаимное перекрытие «слепых зон»

Ключевая инженерная находка Dirty Frag — комбинация двух уязвимостей так, чтобы каждая перекрывала ограничения другой:

• в окружениях, где разрешено создание пользовательских пространств имён, но модуль rxrpc.ko недоступен или не загружается, используется xfrm-ESP вариант;
• в окружениях вроде Ubuntu, где AppArmor блокирует создание пользовательских пространств имён, но rxrpc.ko включён по умолчанию, эксплуатируется RxRPC-вариант.

Таким образом, для большинства массовых дистрибутивов существует хотя бы один рабочий путь эксплуатации, а в некоторых конфигурациях — оба. Исследователь подчёркивает, что Dirty Frag можно успешно эксплуатировать вне зависимости от того, активен ли модуль algif_aead. То есть даже системы, где Copy Fail якобы «закрыт» через блокировку algif_aead, остаются уязвимыми к новой технике.

Контекст угроз и связь с Copy Fail

Copy Fail (CVE-2026-31431), предшествующая уязвимость того же класса, уже активно эксплуатируется в реальных атаках, по данным исследователя. Это важный индикатор: как только для данной категории логических ошибок в подсистемах обработки сетевых данных появляется публичный эксплойт, злоумышленники быстро встраивают его в свои цепочки — от веб-оболочек до контейнерных побегов.

Dirty Frag унаследовал сразу несколько неприятных свойств Copy Fail и Dirty Pipe:

• локальный вектор атаки, но с крайне низким порогом входа (готовый PoC и выполнение в одну команду);
• универсальность — одни и те же примитивы записи применимы к разным целям в памяти (подмена бинарей, модификация /etc/passwd или /etc/shadow, внедрение в процессы безопасности и т.п.);
• отсутствие заметных сбоев в ядре при неудачной эксплуатации, что осложняет детектирование по событиям отказа.

В отличие от Copy Fail, новая техника обходит основную известную временную защиту — блокировку модуля algif_aead. Это делает все текущие «быстрые фиксы» для Copy Fail неполными: инфраструктура, где полагались только на список запрета для algif_aead, получает ложное чувство безопасности при сохранении полного риска локального захвата root.

Оценка воздействия на организации

Наибольшему риску подвержены среды, где потенциальный нарушитель может получить любой локальный доступ — как прямой интерактивный, так и через эксплуатацию иных уязвимостей приложений:

• поставщики облачных и хостинговых услуг с многопользовательскими серверами Linux;
• корпоративные серверы приложений (веб, базы данных, CI/CD), где компрометация одного сервиса даёт локальный доступ низкого уровня;
• виртуальные рабочие столы и терминальные сервера на базе Linux с множеством непривилегированных аккаунтов;
• разработческие и тестовые среды, где часто включены дополнительные подсистемы ядра и меньше жёстких политик безопасности.

Потенциальные последствия при бездействии:

• моментальное повышение привилегий до root после любого локального фута (RCE в веб-приложении, скомпрометированный пользовательский аккаунт, уязвимый контейнер);
• устойчивое закрепление в системе за счёт модификации системных бинарей, загрузчиков, модулей ядра или конфигураций;
• отключение или подмена средств защиты (агенты EDR, журналы аудита);
• нарушение требований соответствия, где контроль административного доступа и целостности систем — ключевой элемент аудита.

Особая опасность в том, что, по словам исследователя, вполне рабочий PoC уже доступен и выполняет эскалацию «одной командой». Это резко сокращает время между появлением уязвимости и её массовым включением в наборы эксплойтов, в том числе автоматизированные.

Практические рекомендации по защите

1. Немедленные временные меры

До выхода официальных патчей для ядра Linux рекомендуется:

• заблокировать загрузку модулей esp4, esp6 и rxrpc:
  • добавить в файлы в /etc/modprobe.d/ строки:
    • blacklist esp4
    • blacklist esp6
    • blacklist rxrpc
  • по возможности выгрузить уже загруженные модули: rmmod esp4 esp6 rxrpc (учитывая риски простоя сервисов).
• осознанно оценить влияние на инфраструктуру: блокировка esp4/esp6 затронет IPSec-туннели, а отключение rxrpc — сервисы, использующие этот протокол.

Это прямо коррелирует с рекомендацией вендора AlmaLinux, описывающего дефект в пути «ESP-in-UDP MSG_SPLICE_PAGES no-COW fast path» и его достижимость через интерфейс XFRM user netlink.

2. Проверка подверженности

Базовые шаги для оценки риска:

• Определить дистрибутивы и версии, находящиеся в зоне риска:
  • базово подтверждены: Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, Fedora 44;
  • при наличии аналогичных версий ядра другие дистрибутивы также могут быть уязвимы.
• Проверить, загружены ли соответствующие модули:
  • lsmod | egrep 'esp4|esp6|rxrpc'
  • при необходимости — modinfo esp4, modinfo rxrpc для подтверждения наличия модулей в системе.
• Уточнить политики создания пользовательских пространств имён:
  • на системах Ubuntu — проверить профили AppArmor;
  • на серверах других дистрибутивов — при возможности ограничить создание user namespace для непривилегированных пользователей.

3. Усиление мониторинга и процедур реагирования

С учётом наличия PoC имеет смысл:

• отслеживать неожиданные загрузки модулей esp4, esp6 и rxrpc (через auditd, systemd-journald, средства мониторинга ядра);
• контролировать запуск инструментов, использующих splice() и sendfile() в нетипичных для системы сочетаниях, особенно от непривилегированных аккаунтов;
• усилить реагирование на любые сигналы локального компромета — от индикаций веб-оболочек до подозрительных бинарей в домашнем каталоге пользователя: при наличии Dirty Frag любой локальный доступ следует рассматривать как потенциальное получение root.

4. Подготовка к установке патчей

Поскольку разработчики ядра были уведомлены об уязвимости 30 апреля 2026 года, в ближайшее время ожидаются обновления в ветках, поддерживаемых дистрибутивами. Рекомендуется заранее:

• запланировать внеочередное обновление ядра с возможными перезагрузками ключевых узлов;
• подготовить тестовый контур для проверки влияния патчей на критичные сервисы (особенно использующие IPSec и RxRPC);
• отслеживать появление записи для Copy Fail CVE-2026-31431 и связанных уязвимостей аналогичного класса в NVD, а также рекомендации вендоров дистрибутивов.

Главный вывод: Dirty Frag открывает универсальный путь к root для любого локального нарушителя на большинстве современных дистрибутивов Linux, а ранее применённые временные меры против Copy Fail уже не обеспечивают достаточной защиты; приоритизируйте немедленную блокировку модулей esp4, esp6 и rxrpc там, где это допустимо бизнес-процессами, и подготовьте инфраструктуру к быстрому развёртыванию обновлённых ядер сразу после выхода официальных патчей.