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 або точне потрапляння в таймінг;
• у разі невдалої спроби експлуатації ядро не падає (немає kernel 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 там, де це допустимо бізнес-процесами, та підготуйте інфраструктуру до швидкого розгортання оновлених ядер одразу після виходу офіційних патчів.