Дослідники з Xint.io та Theori оприлюднили технічні деталі нової критичної уразливості ядра Linux, що отримала назву Copy Fail та ідентифікатор CVE-2026-31431 з оцінкою CVSS 7.8. Помилка дозволяє локальному непривілейованому користувачу отримати повний доступ рівня root практично на будь-якій сучасній системі Linux, що робить її особливо небезпечною для серверних середовищ та контейнерної інфраструктури.
Що таке Copy Fail (CVE-2026-31431) та чому це небезпечно
Copy Fail належить до класу локального підвищення привілеїв (Local Privilege Escalation, LPE). За оприлюдненою інформацією, уразливість дозволяє звичайному користувачу записати чотири повністю контрольовані байти у page cache будь-якого файлу, доступного для читання. Цього виявляється достатньо, щоб змінити поведінку критично важливих бінарних файлів і домогтися виконання коду з правами суперкористувача.
Ключовий ризик полягає в тому, що для експлуатації не потрібен початковий доступ root або спеціальні можливості ядра. Зловмиснику достатньо отримати будь-який локальний акаунт — через фішинг, вразливий веб-сервіс, слабкий пароль або помилки в конфігурації — після чого Copy Fail дає можливість за один крок ескалувати привілеї до рівня керування всією системою.
Технічна сутність уразливості: page cache, AF_ALG та algif_aead
Page cache — це загальний кеш файлових даних у пам’яті ядра Linux. Його спільно використовують усі процеси: якщо сторінка файлу потрапила до page cache, подальші читання цього файлу фактично отримують дані з пам’яті, а не з диска. Тому, якщо зловмисник здатен змінити сторінку у page cache, він по суті підміняє вміст файлу «на льоту» для всіх процесів, які читають ці дані.
Уразливість Copy Fail пов’язана з логічною помилкою в криптографічній підсистемі ядра Linux, а саме в модулі algif_aead, що обробляє AEAD-алгоритми (Authenticated Encryption with Associated Data) через сокетний інтерфейс AF_ALG. Через специфічну оптимізацію стає можливим, щоб сторінка з page cache була включена до записуваного списку призначення (scatterlist) під час виконання криптографічної операції.
Вразливий код було додано до ядра ще внаслідок коміту серпня 2017 року. Це означає, що під впливом Copy Fail перебуває широкий спектр версій ядра та, відповідно, більшість популярних дистрибутивів Linux, які використовували ці гілки без додаткових захисних змін.
Запис у page cache як примітив для атаки
Локальний користувач без спеціальних прав може використати системний виклик splice() разом із сокетом AF_ALG так, щоб у результаті записати кілька байтів у кеш сторінок файлу, який формально відкрито лише для читання і може навіть не належати цьому користувачу. Важливо, що зміни відбуваються в page cache і не обов’язково одразу потрапляють на диск, проте всі процеси, які читають файл, вже бачитимуть модифікований вміст.
Цей примітив відкриває шлях до компрометації setuid-бінарів (наприклад, службових утиліт, що завжди запускаються з правами root). Достатньо змінити кілька байтів у критичній ділянці такого бінарного файлу, щоб перехопити потік виконання і запустити довільний код із максимальними привілеями. Для зловмисників це означає надійний та відносно простий метод переходу від «користувача застосунку» до повного контролю над операційною системою.
Вплив на дистрибутиви Linux та загрози для контейнерів
Оскільки вразливий код присутній у ядрі Linux із 2017 року, під загрозою опиняються практично всі основні дистрибутиви, включно з Amazon Linux, Red Hat Enterprise Linux (RHEL), SUSE, Ubuntu та іншими системами, побудованими на уразливих гілках ядра. Для багатьох організацій це означає потенційний вплив як на «голі» сервери, так і на хост-системи в хмарній інфраструктурі.
Хоча Copy Fail не є віддаленою уразливістю сам по собі, він різко знижує «вартість» подальшої атаки після початкового проникнення. Будь-яке компрометоване локальне середовище — від облікового запису розробника до технічного користувача в контейнері — може стати трампліном до повного захоплення хосту.
Особливо критичним є крос-контейнерний аспект. Page cache ядра спільний для всіх контейнерів і хост-системи, тож процес усередині формально ізольованого контейнера може модифікувати вміст бінарів за його межами. Це створює реальну можливість виходу з контейнера (container escape), обходу sandboxing-механізмів та отримання root-доступу вже на рівні основної операційної системи.
Copy Fail та Dirty Pipe: схожі примітиви, інша підсистема
За своєю природою Copy Fail близька до широко відомої уразливості Dirty Pipe (CVE-2022-0847), яка також дозволяла запис у page cache файлів, відкритих лише для читання. В обох випадках зловмисники отримують потужний примітив для переписування чутливих даних без прямого запису на диск.
Водночас Copy Fail реалізує цей примітив в іншому контексті. Якщо Dirty Pipe експлуатувала помилки в підсистемі роботи з pipe, то Copy Fail базується на логічній ваді в криптографічному модулі algif_aead та інтерфейсі AF_ALG. Експлуатація вважається особливо небезпечною, оскільки:
- не потребує складних гонок (race condition) чи знання внутрішніх зсувів ядра;
- експлойт може бути реалізований у вигляді дуже компактного скрипта (порядку кількох сотень байт коду на Python чи C);
- одна і та сама техніка працює крос-дистрибутивно, з мінімальними змінами або взагалі без них;
- атака залишає мінімальний слід у логах, що суттєво ускладнює виявлення інциденту стандартними методами моніторингу.
Як захистити Linux-інфраструктуру від Copy Fail
Після публічного розкриття деталей CVE-2026-31431 виробники Linux-дистрибутивів почали випускати оновлення ядра та бюлетені безпеки. Першочергове завдання для адміністраторів та команд безпеки — максимально швидко встановити актуальні патчі ядра з офіційних репозиторіїв (RHEL, Ubuntu, SUSE, Amazon Linux та ін.). Зволікання напряму підвищує ризики для критичних систем і середовищ контейнеризації.
Паралельно до встановлення оновлень доцільно:
- посилити контроль за локальним доступом до серверів і робочих станцій (MFA, політика мінімальних привілеїв, обмеження SSH-доступу, жорсткіші вимоги до паролів);
- провести інвентаризацію setuid-бінарів і, де можливо, зменшити їх кількість або замінити на більш безпечні механізми делегування прав (sudo, policykit тощо);
- переглянути політики ізоляції контейнерів, пам’ятаючи, що namespase-ізоляція не захищає від уразливостей ядра; для найкритичніших сервісів доцільно розглянути додаткові шари захисту (наприклад, sandbox на рівні гіпервізора або рішення типу gVisor/Kata Containers);
- налаштувати моніторинг аномальної активності, зокрема викликів
AF_ALG, нетипового використання setuid-програм та підозрілих відхилень у поведінці контейнерів.
Copy Fail переконливо демонструє, що навіть відносно невелика логічна помилка в спеціалізованому модулі ядра може призвести до масштабних наслідків — повного захоплення серверів, виходу з контейнерів і обходу песочниць. Щоб мінімізувати ризики, організаціям варто не лише оперативно застосовувати патчі, а й системно переглянути архітектуру захисту Linux-інфраструктури, впровадити принцип найменших привілеїв, розвивати практики DevSecOps та постійно відстежувати появу нових класів атак на рівні ядра.
