May-Storm-in-the-Linux-Kernel

Травень 2026 запам’ятається нам як один з найтурбулентніших періодів за останні роки. Одну за одною знаходять критичні вразливостей в ядрі Linux, які об’єднані архітектурною проблемою в роботі з кешем сторінок пам’яті (Page Cache).

Можна сказати, це новий клас багів, що дозволяє непривілейованому користувачу отримати права root. Розберемо що сталося, чому це небезпечно і як захиститись.

Як все відбувалось: Від Copy Fail до Dirty Frag#

Усе почалося наприкінці квітня з виявлення вразливості Copy Fail (CVE-2026-31431). Дослідники з’ясували, що через невдалу оптимізацію роботи з пам’яттю (Zero-Copy) у криптографічному модулі ядра, зловмисник може за допомогою системного виклику splice() перезаписати дані в оперативній пам’яті для будь-якого файлу, навіть якщо він доступний лише для читання (read-only).

Ефект доміно не змусив себе чекати. Вже на початку травня, використовуючи автоматизовані ШІ-інструменти для пошуку схожих паттернів, спільнота виявила серію нових вразливостей, які отримали назву Dirty Frag (CVE-2026-43284, CVE-2026-43500) та Fragnesia (CVE-2026-46300). Цього разу проблема зачепила мережеві підсистеми ядра (компоненти IPsec та модуль RxRPC).

Схема атаки проста, але руйнівна:
Хакер не змінює файли на диску. Замість цього він «на льоту» підміняє кілька байтів у Page Cache (RAM) для таких критичних утиліт як /usr/bin/su. Як результат - система дозволяє викликати оболонку від root-користувача.

Чому це критично?#

Хоча ці вразливості належать до класу LPE (Local Privilege Escalation) - тобто вимагають початкового доступу до системи й не працюють «з вулиці» самі по собі - рівень небезпеки оцінюється як високий.

  1. Ідеальна зброя для другого етапу атак. Якщо у вашому вебдодатку, CMS або PHP-скрипті є хоч найменша діра, яка дозволяє виконати довільний код, зловмисник використає Copy Fail або Dirty Frag, щоб за секунду стати повновладним господарем сервера.
  2. Загроза для Kubernetes та CI/CD. Експлойти стабільно працюють усередині ізольованих контейнерів та Docker-раннерів. Якщо ви запускаєте сторонній чи неперевірений код у хмарі, зловмисники можуть легко «вистрибнути» з обмеженого контейнера та скомпрометувати всю ноду (вузол) кластера.
  3. Публічна доступність експлойтів. Робочі концептуальні коди (PoC) вже є у відкритому доступі. Вони написані на Python, займають менше ніж 1 кілобайт і працюють безвідмовно на більшості популярних дистрибутивів.

Як захиститися?#

Крок 1. Головний пріоритет - Оновлення ядра#

Виробники найбільших дистрибутивів (Ubuntu, Red Hat Enterprise Linux, Rocky Linux, AlmaLinux, AWS Linux) вже випустили або активно випускають офіційні патчі.

Виконайте повне оновлення системи та обов’язково заплануйте перезавантаження серверів, щоб нове ядро вступило в силу:

# Для Ubuntu / Debian:
sudo apt update && sudo apt upgrade -y && sudo reboot

# Для RHEL / Rocky Linux / AlmaLinux:
sudo dnf update -y && sudo reboot

Якщо оновлень ще немає під вашу ОС, або на зараз ви не можете запланувати перезавантаження - переходьте до кроку 2.

Крок 2. Тимчасове блокування модулів (Mitigation)#

Якщо з якихось причин ви не можете перезавантажити критично важливий сервер просто зараз, заблокуйте завантаження вразливих модулів ядра на рівні конфігурації.

Створіть конфігураційні файли для заборони:

# Блокування модуля для Copy Fail
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
# Для RHEL algif_aead модуль вбудовано, 
# тому доведеться блокувати виклик через grub і обов'якзково перезавантажити 
/sbin/grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"

# Блокування модулів для Dirty Frag / Fragnesia
printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf

# Вивантаження модулів з пам'яті (якщо вони не використовуються активними процесами)
rmmod algif_aead esp4 esp6 rxrpc 2>/dev/null || true

Примітка: Вимкнення цих модулів не зашкодить стандартним сервісам типу SSH або шифруванню LUKS, але може вплинути на специфічні конфігурації IPsec VPN. Перед застосуванням на продакшені протестуйте рішення.

Висновок#

Ситуація з Page Cache у Linux вкотре доводить: безпека - це безперервний процес. Навіть код, який роками вважався стабільним та оптимізованим, під пильним оком сучасних інструментів аналізу виявляється вразливим. Не зволікайте з патч-менеджментом. Безпечного вам адміністрування!