DirtyFrag: новая дыра в ядре Linux и что с этим делать прямо сейчас

Представь: твой WordPress-сервер работает нормально. Nginx отдаёт страницы, fail2ban банит ботов, Cloudflare фильтрует мусор. Ты настроил ModSecurity, поставил Wordfence, закрыл лишние порты. Сервер — крепость.

А потом кто-то находит SQL-инъекцию в старом плагине, получает RCE от имени www-data, запускает одну команду — и становится root.

Добро пожаловать в DirtyFrag.

ЧТО СЛУЧИЛОСЬ

7 мая 2026 года исследователь по безопасности Хюнву Ким опубликовал технические детали уязвимости в ядре Linux, которую назвал DirtyFrag. Эмбарго было нарушено посторонним лицом до того, как дистрибутивы успели подготовить патчи — и рабочий эксплойт оказался в открытом доступе раньше, чем исправление.

Уязвимость получила два CVE:
— CVE-2026-43284 — xfrm-ESP Page-Cache Write (IPsec, модули esp4/esp6)
— CVE-2026-43500 — RxRPC Page-Cache Write (модуль rxrpc)

CVSS 3.1: 8.8 (HIGH) для CVE-2026-43284 и 7.8 (HIGH) для CVE-2026-43500.

Затронуты: Ubuntu, Debian, RHEL, AlmaLinux, Fedora, openSUSE, CentOS Stream — то есть практически все серверные дистрибутивы. Уязвимость присутствует в ядрах начиная примерно с 2017 года.

КАК ЭТО РАБОТАЕТ (БЕЗ ПОГРУЖЕНИЯ В АССЕМБЛЕР)

Ядро Linux использует page cache — что-то вроде оперативного буфера для файлов с диска. Когда ядро читает /etc/passwd или /usr/bin/su, оно кладёт содержимое в page cache и дальше работает с кэшированной версией.

DirtyFrag использует два бага в путях расшифровки IPsec ESP и rxrpc. При определённых условиях (передача данных через splice(2)/sendfile(2)) ядро расшифровывает данные прямо поверх страниц, на которые у непривилегированного процесса ещё есть ссылка. Итог — запись в page cache без авторизации.

Что это даёт атакующему? Возможность подменить содержимое системного файла в памяти. Например, модифицировать /usr/bin/su так, чтобы он не спрашивал пароль, а сразу открывал root shell. На диске файл остаётся нетронутым — ядро просто отдаёт «свежую» страницу из кэша.

Три свойства, которые делают DirtyFrag особенно неприятным:
— Нет race condition. Это детерминированный баг, а не гонка.
— Высокий процент успешной эксплуатации.
— Ядро не падает даже при неудачной попытке — атаку сложно обнаружить по крашам.

НО ЕСТЬ НЮАНС

DirtyFrag — это LPE (Local Privilege Escalation), не удалённый эксплойт. Атакующий должен уже иметь возможность выполнять код на сервере.

Типичная цепочка атаки:

1. RCE через уязвимый плагин WordPress, устаревший PHP, незакрытый сервис
2. Атакующий работает от имени www-data или другого непривилегированного пользователя
3. Запускает DirtyFrag — и получает root

Именно поэтому хорошо настроенный стек (Cloudflare + WAF + nftables + fail2ban) снижает риск, но не устраняет его полностью. Если где-то есть щель для первичного доступа — DirtyFrag превращает её в полный контроль над сервером.

ЧТО ДЕЛАТЬ ПРЯМО СЕЙЧАС

Шаг 1. Проверь, загружены ли уязвимые модули

lsmod | grep -E 'esp4|esp6|rxrpc'

Если вывод пустой — они не загружены. Но blacklist всё равно нужен: модули могут загрузиться при следующей перезагрузке или при определённых сетевых операциях.

Шаг 2. Заблокируй модули (основной workaround)

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf"
sudo rmmod esp4 esp6 rxrpc 2>/dev/null
echo "Готово"

Это безопасно для большинства серверов. Исключения: если используешь IPsec VPN или AFS — сначала уточни, нужны ли тебе эти модули.

Шаг 3. Сбрось page cache

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

sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"

Это безопасная операция на живом сервере. Ядро просто освободит чистый кэш, следующее чтение файлов пойдёт с диска.

Шаг 4. Обнови ядро как только выйдет патч

Ubuntu/Debian:

sudo apt update && sudo apt upgrade -y
sudo reboot

RHEL/AlmaLinux/Fedora:

sudo dnf clean metadata && sudo dnf upgrade -y
sudo reboot

После перезагрузки с патчем удали workaround:

sudo rm /etc/modprobe.d/dirtyfrag.conf

Шаг 5. Изолируй PHP-FPM через systemd

Если не сделано — это отдельная хорошая практика, которая ограничивает ущерб от первичного RCE:

sudo systemctl edit php8.3-fpm

Добавь:

[Service]
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ProtectHome=yes

sudo systemctl daemon-reload && sudo systemctl restart php8.3-fpm

NoNewPrivileges=yes — это именно та директива, которая мешает процессу получить привилегии выше тех, с которыми он запущен. Даже если www-data запустит DirtyFrag — повышение заблокировано.

Шаг 6. Отдельный сервер с БД — не забудь про него

«У меня БД в приватной сети, туда никто не доберётся» — классическое заблуждение. Если веб-сервер скомпрометирован, атакующий уже внутри твоей сети. Один прыжок — и он на DB-сервере. Дальше DirtyFrag делает своё дело.

На DB-сервере те же две минуты работы. IPsec там точно не нужен — блокируй без раздумий:

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf"
sudo rmmod esp4 esp6 rxrpc 2>/dev/null
sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"

И NoNewPrivileges=yes для самой БД:

sudo systemctl edit postgresql   # или mysql / mariadb

[Service]
NoNewPrivileges=yes
PrivateTmp=yes

sudo systemctl daemon-reload && sudo systemctl restart postgresql

ПРОВЕРИТЬ СТАТУС ПАТЧА

Ubuntu публикует обновления здесь: https://ubuntu.com/security/notices
AlmaLinux: https://errata.almalinux.org
RHEL: https://access.redhat.com/security/vulnerabilities/RHSB-2026-003

Следи за обновлениями ядра — как только появится версия с пометкой «fixes CVE-2026-43284» — обновляй и перезагружай.

ЕСЛИ СЕРВЕР УЖЕ МОГ БЫТЬ СКОМПРОМЕТИРОВАН

Признаки, на которые стоит обратить внимание:
— Неожиданные процессы от root или незнакомых пользователей
— Изменения в /etc/passwd, /etc/sudoers, /etc/crontab (даже если файл на диске выглядит нормально — проверь хеш)
— Новые SSH-ключи в ~/.ssh/authorized_keys
— Подозрительный исходящий трафик в логах nftables

# Проверить хеши системных бинарников
sudo debsums -c 2>/dev/null | head -20   # Debian/Ubuntu
sudo rpm -Va 2>/dev/null | grep -E '^..5' | head -20  # RHEL/AlmaLinux

# Посмотреть последние входы
last -20
lastb -20

# Процессы от root
ps aux | grep ^root

ИТОГ

DirtyFrag — не повод для паники, но повод для действий. Уязвимость реальная, эксплойт публичный, патчей пока нет у части дистрибутивов.

Три вещи, которые нужно сделать сегодня:

1. Добавить blacklist модулей — две команды, пять минут.
2. Убедиться, что PHP-FPM изолирован через systemd с NoNewPrivileges=yes.
3. Подписаться на security-рассылку своего дистрибутива и обновить ядро как только выйдет патч.

Если твой стек уже включает Cloudflare + WAF + fail2ban + nftables — ты в хорошей позиции. DirtyFrag не работает без первичного доступа, а твоя задача — этот доступ не дать.

---

Автор: sysadmin.courses
Курс «Linux Server Security: от новичка до профи» — практическая безопасность Linux-серверов для тех, кто хочет понимать, а не только копировать команды.