Новости

Dirty Frag среди 432 CVE: какие Linux-хосты патчить первыми

Дмитрий Потоцкий 1 мин чтения
Dirty Frag среди 432 CVE: какие Linux-хосты патчить первыми

19 и 20 июля команда ядра Linux опубликовала 432 CVE. До этой пачки за июль набралось ещё больше 40 записей. Читать бюллетени по порядку уже поздно: цепочку Dirty Frag применяли в атаках 11 мая — через несколько дней после публикации PoC (dailysecurityreview.com; tenable.com).

У тебя одно maintenance window и десятки Linux-хостов: CI-раннеры, Kubernetes-ноды, общие серверы разработки. Разбирать 432 бюллетеня не нужно. Сначала найди машины, где локальный пользователь или процесс в контейнере может получить root. Затем обнови ядро и после перезагрузки проверь, что хост запустил исправленную версию.

Dirty Frag даёт root через две ошибки ядра

Dirty Frag объединяет CVE-2026-43284 и CVE-2026-43500. Первая ошибка находится в обработке xfrm-ESP для IPsec и даёт примитив записи четырёх байт. Вторая затрагивает RxRPC и позволяет создать namespace с нужными привилегиями. В связке они дают непривилегированному локальному пользователю root на основных дистрибутивах Linux.

Гонка потоков эксплойту не нужна. Исследователь описывает его как детерминированный и сообщает о высокой вероятности успеха. Публичный PoC появился 8 мая. Уже 11 мая Microsoft Defender зафиксировал ограниченную эксплуатацию цепочки: атакующие меняли файлы LDAP-аутентификации GLPI и получали доступ к данным PHP-сессий (tenable.com; dailysecurityreview.com).

Поэтому Dirty Frag должна подняться в очереди на патчинг. CVSS 7,8 у CVE-2026-43284 выглядит спокойнее очередной «критической десятки». Но здесь уже есть публичный PoC, подтверждённые атаки и прямой путь от локального пользователя до root. Эти три факта полезнее одной цифры из бюллетеня.

В начало очереди ставь раннеры и общие хосты

Сначала проверь машины, где недоверенный код уже работает локально:

  • CI/CD-раннеры;
  • общие серверы разработки;
  • multi-user-хосты;
  • контейнерные ноды;
  • серверы, где пользователи запускают плагины, сборки или пользовательские задания.

На таких хостах атакующий уже получает точку входа, нужную локальной уязвимости. В отдельных конфигурациях Dirty Frag также позволяет выйти из контейнера. Запрет интерактивного SSH поэтому не снимает риск (dailysecurityreview.com; knightli.com).

Возраст дистрибутива тоже не годится как фильтр. Уязвимый код xfrm-ESP находится в upstream-ядре с 2017 года, код RxRPC — с 2023-го. Под ударом могут быть дистрибутивы, выпущенные за последние девять лет.

Цепочку проверили как минимум на трёх системах:

  • Ubuntu 24.04.4 с ядром 6.17.0-23-generic;
  • RHEL 10.1 с 6.12.0-124.49.1.el10_1.x86_64;
  • AlmaLinux 10 с 6.12.0-124.52.3.el10_1.x86_64.

Это подтверждённые уязвимые версии, а не полный список. Если ядра твоего хоста здесь нет, защищённым оно от этого не становится.

Blacklist для Copy Fail не останавливает Dirty Frag

Dirty Frag легко перепутать с Copy Fail: обе ошибки повышают локальные привилегии и связаны с записью в page cache. Но точки входа у них разные.

Copy Fail, она же CVE-2026-31431, проходит через algif_aead и пользовательский криптографический API AF_ALG. Dirty Frag использует esp4, esp6 и rxrpc (dailysecurityreview.com; knightli.com). Blacklist для algif_aead её не останавливает. Патч Copy Fail новую цепочку тоже не закрывает.

Если хост нельзя перезагрузить в ближайшее окно, для Dirty Frag можно временно отключить модули esp4, esp6 и rxrpc. Но сначала проверь зависимости. esp4 и esp6 обрабатывают IPsec, а отключение rxrpc сломает нагрузки, использующие этот транспорт.

Проверь, загружены ли модули:

lsmod | grep -E '^(esp4|esp6|rxrpc)\b'

Перед выгрузкой найди процессы и сервисы, которым нужны IPsec или RxRPC. Отключение модулей сократит экспозицию, но пакет с исправлением и перезагрузку не заменит.

Проверь установленное и запущенное ядро

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

Версию работающего ядра покажет команда:

uname -r

На Debian и Ubuntu выведи установленные пакеты ядра:

dpkg-query -W 'linux-image-*' 2>/dev/null

На RHEL, AlmaLinux, Fedora и Amazon Linux:

rpm -q kernel

После перезагрузки снова запусти uname -r и сравни вывод с исправленным пакетом из бюллетеня своего дистрибутива. Файл нового ядра в /boot ничего не говорит о версии, которая сейчас обслуживает процессы.

Исправление CVE-2026-43284 вышло в mainline и пакетах Red Hat, Ubuntu, Amazon Linux, Fedora и AlmaLinux. На 11 мая патч CVE-2026-43500 ещё дорабатывали; Red Hat отслеживал всю цепочку в бюллетене RHSB-2026-003. Проверяй у поставщика статус обеих CVE. Патч одной половины цепочки не гарантирует, что закрыта вторая.

Один maintenance window: порядок действий

Не трать окно на последовательный просмотр 432 записей. Сделай пять проверок:

  1. Выгрузи список CI-раннеров, контейнерных нод, multi-user-серверов и общих машин разработки.
  2. На каждом хосте сохрани вывод uname -r и список установленных пакетов ядра.
  3. Найди в бюллетене дистрибутива статус обеих записей: CVE-2026-43284 и CVE-2026-43500.
  4. Установи исправленное ядро, перезагрузи хост и ещё раз проверь uname -r.
  5. Если перезагрузка запрещена, проверь использование IPsec и RxRPC. После этого оцени временное отключение esp4, esp6 и rxrpc.

Для следующей пачки CVE держи четыре фильтра: подтверждённая эксплуатация, публичный PoC, путь до root и недоверенный локальный код. Dirty Frag проходит по всем четырём (dailysecurityreview.com; tenable.com; knightli.com). Общие хосты с уязвимым ядром ставь в ближайшее окно, а не в хвост очереди из 432 строк.

Похожие материалы