Dirty Frag: root в Linux, даже если user namespaces отключены

Dirty Frag — Linux kernel LPE-цепочка для получения root. Главный риск: отключение unprivileged user namespaces само по себе не закрывает эксплуатацию.

2026-05-13 GIGATAP Team #security
#linux#kernel#local-privilege-escalation

Dirty Frag: root в Linux, даже если user namespaces отключены

Недавно раскрытая уязвимость локального повышения привилегий в Linux kernel, отслеживаемая как CVE-2026-31431 и описанная в источнике с оценкой CVSS 7.8, представлена как неисправленная и активно эксплуатируемая в реальных атаках. В публичном описании её подают не как один узкий баг, а как класс уязвимостей под названием Dirty Frag, который может дать root непривилегированному локальному пользователю на популярных Linux-дистрибутивах.

Главный практический смысл Dirty Frag: привычная защита вроде отключения unprivileged user namespaces может оказаться недостаточной, потому что цепочка использует альтернативные пути эксплуатации в зависимости от конфигурации системы.

Что известно о Dirty Frag#

Security researcher Hyunwoo Kim (@v4bel) описывает Dirty Frag как цепочку из двух связанных примитивов записи в page cache:

  • xfrm-ESP Page-Cache Write — в подсистеме IPSec/xfrm
  • RxRPC Page-Cache Write — в fast paths RxRPC

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

Источник характеризует Dirty Frag как детерминированный logic bug, а не как race condition, зависящий от таймингов:

  • race condition не требуется
  • заявлен высокий success rate
  • kernel, по описанию источника, не уходит в panic при неудачной попытке эксплуатации

Если эти свойства подтверждаются в реальных условиях, это важно для incident response: такой exploit нельзя списывать как нестабильный локальный PoC, который «вряд ли сработает».

Кого это может затронуть#

Успешная эксплуатация может позволить непривилегированному локальному пользователю получить root. В источнике перечислены примеры затронутых окружений:

  • Ubuntu 24.04.4
  • RHEL 10.1
  • openSUSE Tumbleweed
  • CentOS Stream 10
  • AlmaLinux 10
  • Fedora 44

Этот список стоит воспринимать как заявленные примеры, а не как полную матрицу совместимости. Для kernel LPE реальная экспозиция зависит от конкретной версии kernel, config, доступных modules, sysctl-настроек и достижимых code paths.

Фактор срочности высокий, потому что источник утверждает сразу три вещи:

  • проблема на момент публикации не исправлена
  • наблюдается активная эксплуатация in the wild
  • существует рабочий proof-of-concept, который может «получить root одной командой»

Особенно внимательно стоит проверить multi-user systems, shared servers, CI runners, университетские серверы, developer workstations и любые среды, где недоверенный код может выполняться локально.

Почему отключение user namespaces не является silver bullet#

Dirty Frag важен не только самим фактом LPE, а тем, что цепочка учитывает реальные hardening-настройки дистрибутивов.

xfrm-ESP: мощный путь, но зависит от namespaces#

Примитив xfrm/ESP описывается как 4-byte store primitive, который может перезаписать небольшой объём данных в page cache kernel.

Но у этого пути есть ограничение: для запуска атакующему нужно создать namespace. В источнике отмечается, что Ubuntu блокирует создание unprivileged user namespace через sysctl controls, поэтому xfrm-ESP путь в такой конфигурации не запускается.

Практический вывод: если вы отключили unprivileged user namespaces, это снижает риск по одному пути эксплуатации, но не доказывает, что система защищена от Dirty Frag полностью.

RxRPC: не требует namespaces, но зависит от module#

Вариант RxRPC описывается как путь, который не требует создания namespace. Это делает его особенно важным для систем, где user namespaces уже отключены.

Но у него есть другое ограничение: в источнике указано, что module rxrpc.ko не входит в большинство distributions. Пример из статьи: дефолтная сборка RHEL 10.1 не поставляет rxrpc.ko, тогда как на Ubuntu этот module загружается по умолчанию.

Именно поэтому простая проверка одного mitigation недостаточна. Нужно смотреть, какие kernel modules реально доступны и загружены на ваших hosts.

Почему цепочка опасна на практике#

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

  • если разрешены unprivileged user namespaces, может использоваться xfrm/ESP
  • если user namespaces заблокированы, но доступен RxRPC, может использоваться RxRPC
  • если один code path недоступен, второй может оставаться достижимым

Для защитника это означает: оценивать нужно не отдельную настройку, а полный набор локально достижимых kernel attack surface.

Техническая суть по описанию источника#

Источник приводит описание, приписываемое AlmaLinux: flaw находится в “ESP-in-UDP MSG_SPLICE_PAGES no-COW fast path” и достижим через XFRM user netlink interface.

Общий паттерн выглядит так:

  • receive path выполняет decrypt in place поверх page fragments
  • эти fragments могут быть externally-backed pages, например pipe pages, присоединённые через splice(2), sendfile(2) или MSG_SPLICE_PAGES
  • если copy-on-write semantics не соблюдаются корректно, возникает возможность записи в page cache там, где её быть не должно

На уровне эксплуатации это превращается в локальный примитив записи, который затем используется для повышения привилегий до root.

Что делать сейчас#

Пока нет подтверждённого исправления в вашем vendor kernel, практический план должен быть таким:

  1. Проверить vendor advisories. Отслеживайте бюллетени вашего дистрибутива по CVE-2026-31431 и Dirty Frag. Установите kernel update сразу после выхода.

  2. Проверить unprivileged user namespaces. На Linux hosts проверьте, разрешены ли они политикой sysctl. Если они не нужны рабочим нагрузкам, держите их отключёнными.

  3. Проверить RxRPC. Убедитесь, присутствует ли rxrpc.ko, загружен ли module и нужен ли он реально. Если RxRPC не используется, рассмотрите blacklist или запрет загрузки module через стандартные механизмы вашей платформы.

  4. Снизить локальную экспозицию. Ограничьте запуск недоверенного кода на shared hosts, CI runners и developer machines. Dirty Frag относится к local privilege escalation, поэтому первичный доступ к shell, job runner или sandbox может стать путём к root.

  5. Искать признаки постэксплуатации. Проверяйте неожиданные root-процессы, изменения в persistence-механизмах, новые setuid-файлы, подозрительные kernel/module events и аномальные действия локальных пользователей.

  6. Не полагаться на один hardening control. Отключение user namespaces полезно, но Dirty Frag как раз показывает, что один mitigation может быть обойдён альтернативным kernel path.

Короткий вывод#

Dirty Frag опасен не только тем, что даёт local root. Его главный урок для defenders: проверяйте фактическую kernel attack surface на своих системах, а не наличие одной “безопасной настройки”. В приоритете — vendor patch, аудит user namespaces, проверка rxrpc.ko и ограничение запуска недоверенного локального кода.