CVE-2026-31431: уязвимость в ядре Linux 9 лет давала root-доступ
В конце апреля в ядре Linux обнаружили уязвимость CVE-2026-31431, получившую имя Copy Fail. Она присутствовала в ядре с 2017 года, затрагивает Ubuntu, RHEL, WSL2 и другие дистрибутивы, а рабочий эксплойт умещается в 732 байта кода на Python. CISA уже пометила её как активно эксплуатируемую.
Что именно сломано и как давно
Корень проблемы — коммит 72548b093ee3, добавленный в ядро Linux в 2017 году. Он внёс поддержку операций «на месте» для AEAD-шифрования в модуле algif_aead. Реализация оказалась с дефектом обработки буферов, который никто не замечал девять лет.
Другие источники указывают, что проблема могла накапливаться через три разных коммита — в 2011, 2015 и 2017 годах. Точная цепочка до конца не установлена, но результат один: под угрозой оказались все ядра, выпущенные в период с 2017 по 2026 год.
CVSS-оценка — 7,8 из 10. Высокая, но не критическая: для эксплуатации нужен локальный доступ к системе. На практике это ограничение почти ничего не значит — в связке с любой удалённой уязвимостью оно снимается.
Как работает атака
Криптографический алгоритм ядра authencesn использует часть выделенной памяти как временный буфер. Четыре байта при этом записываются напрямую в страницы файлового кэша. По данным Kaspersky, это даёт атакующему возможность контролируемо изменять содержимое кэша любого читаемого файла.
Эксплойт весит 732 байта и написан на Python. Он записывает четыре управляемых байта в кэш исполняемого файла с битом setuid — например, sudo или passwd. Код программы меняется прямо в оперативной памяти. При следующем запуске она выполняет произвольные действия с правами root. Файл на диске при этом остаётся нетронутым.
Обнаружить атаку сложнее, чем провести: эксплойт использует легитимные системные вызовы, неотличимые от штатной работы приложений. Видимые следы всё же есть — командные строки, вызывающие привилегированные suid-утилиты: su, sudo, mount, passwd, newgrp и другие. Ещё один сигнал — любой Python-процесс, запускающий системный shell.
Почему это особенно опасно для контейнерных сред
Docker, LXC и Kubernetes по умолчанию предоставляют процессам внутри контейнера доступ к подсистеме AF_ALG — при условии, что модуль algif_aead загружен в ядре хоста. Это стандартная конфигурация большинства production-окружений.
Следствие прямое: Copy Fail создаёт риск выхода за пределы контейнера и получения контроля над физическим хостом. Для облачной инфраструктуры, где на одном хосте крутятся десятки изолированных окружений, это означает потенциальный захват всего узла через один скомпрометированный контейнер.
Михаил Зайцев из SEQ формулирует точно: «Присвоенные уязвимости 7,8 балла CVSS впору умножать на последствия успешной эксплуатации, особенно в облачной или контейнерной средах, а также на количество дистрибутивов Linux, которые она затрагивает». Добавлю от себя: девять лет в ядре — это достаточный срок, чтобы допустить, что о баге знали не только исследователи.
Что делать прямо сейчас
Патч уже существует. Уязвимость закрыта в версиях ядра Linux 6.18.22, 6.19.12 и 7.0. Обновление — приоритет номер один для любой инфраструктуры на Linux, особенно если там работают контейнеры.
• Проверить версию ядра на всех серверах: uname -r. Всё ниже 6.18.22 — уязвимо.
• Приоритет на обновление: хосты с Docker, Kubernetes, LXC — там риск выхода из контейнера.
• Проверить, загружен ли модуль algif_aead: lsmod | grep algif_aead. Если не нужен — выгрузить.
• Настроить SIEM на детектирование: Kaspersky опубликовал рекомендации по auditd-правилам на Securelist.
• Мониторить Python-процессы, запускающие shell, и вызовы suid-утилит из нестандартных контекстов.
Отдельный вопрос, который остаётся без ответа: если баг жил в ядре девять лет и эксплойт умещается в 732 байта — кто ещё знал об этом до публикации в апреле 2026-го?
—
[ВКонтакте](https://vk.com/ciologia)
[Telegram](https://t.me/CIOlogia)
[Habr](https://habr.com/ru/users/CIOlogia/posts/)
[TenChat](https://tenchat.ru/ciologia)
[LinkedIn](https://www.linkedin.com/in/vladislav-prokopovich-bb808376/)