Двадцать девятого апреля 2026 года в мире системного администрирования случился один из тех редких дней, когда команда обновить серверы перестаёт быть рутиной и становится боевой задачей. Исследователи компании Theori и группа Xint Code раскрыли подробности уязвимости с идентификатором CVE-2026-31431, моментально получившей человекочитаемое имя Copy Fail. По степени распространённости и простоте эксплуатации она встала в один ряд с легендарными Dirty Cow и Dirty Pipe, а по некоторым параметрам даже превзошла их. Уязвимость живёт в ядре Linux с июля 2017 года, прячется в криптографической подсистеме и позволяет любому локальному пользователю стать root всего за несколько миллисекунд. При этом эксплоит умещается в 732 байта кода на Python и одинаково хорошо работает на Ubuntu, Red Hat, SUSE, Debian, Amazon Linux и десятках других дистрибутивов без какой-либо адаптации под конкретную сборку.
Как небольшая оптимизация 2017 года обернулась универсальной отмычкой к ядру
Корень проблемы уходит в коммит 72548b093ee3, добавленный в ядро летом 2017 года. Тогдашняя задача была вполне утилитарной: ускорить операции аутентифицированного шифрования через интерфейс AF_ALG, дав пользовательскому пространству прямой доступ к встроенным криптографическим функциям ядра. Ради скорости разработчики реализовали так называемую in-place обработку, при которой исходный и результирующий буферы фактически указывают на одну и ту же область памяти. Это сэкономило выделение и копирование данных, дало небольшой, но приятный прирост производительности и было вполне логичным решением для своего времени.
Спустя девять лет именно эта оптимизация стала фундаментом для одного из самых элегантных эксплоитов десятилетия. Дело в том, что внутри криптографического шаблона authencesn, отвечающего за схему шифрования с расширенным порядковым номером, реализован механизм временной перезаписи четырёх байт в выходном буфере. Алгоритм использует кусок результирующей памяти как черновик и потом возвращает данные на место. В нормальных условиях это безобидная служебная операция. Но когда исходный и выходной буферы совмещены через ту самую in-place оптимизацию, а в источник через системный вызов splice подброшены страницы из кеша файла, четыре служебных байта неожиданно записываются прямо в кеш памяти любого читаемого файла. Без проверки прав, без участия обычного пути записи, без касания диска.
Почему именно page cache превращает мелкий баг в катастрофу
Ключ к пониманию масштаба находится в том, как Linux обращается с исполняемыми файлами. Когда система запускает программу, ядро не читает её с диска заново при каждом обращении - оно использует страничный кеш, единый общий буфер в оперативной памяти, через который проходят все обращения к файлам. Кеш существует один на всю систему и разделяется между всеми процессами, всеми пользователями и даже между всеми контейнерами на одном узле.
Из этого следует неприятный вывод. Если злоумышленник умеет писать четыре произвольных байта в произвольное место страничного кеша, он может незаметно подменить инструкции в памяти любого исполняемого файла, который ему доступен на чтение. Файл на диске остаётся нетронутым, контрольные суммы и системы проверки целостности молчат, журналы аудита не реагируют. Но в момент, когда привилегированный процесс или setuid-бинарник вроде su или sudo запускается, ядро берёт инструкции из заражённого кеша, и подменённый код выполняется с правами root.
Атака получается тихой, повторяемой и не требует ни обхода ASLR, ни выигрыша в гонках, ни специфичных смещений ядра. Исследователи Xint описывают её как прямолинейный логический баг без какой-либо случайности. Тот же самый Python-скрипт работает одинаково на ядре 4.14, на 6.18, на ARM-серверах AWS и на x86-машинах в стойках корпоративных дата-центров.
Кто оказался в зоне поражения и почему облако стоит на первой линии огня
Под удар попали ядра Linux версий с 4.14 (июль 2017 года) до 6.19.12 включительно, а также все младшие LTS-ветки 6.12, 6.6, 5.15 и 5.10 без свежих бэкпортов. Это означает, что в группе риска оказались Debian, Ubuntu всех релизов до 26.04 Resolute, Red Hat Enterprise Linux вплоть до 10.1, SUSE 16, AlmaLinux, Amazon Linux 2023 и фактически любая система, основанная на стандартном ванильном ядре.
Особую тревогу вызывают облачные среды. Microsoft Defender в своём отчёте прямо указал на миллионы кластеров Kubernetes, потенциально подверженных эксплуатации. И тут срабатывает второе свойство уязвимости, превращающее её из локальной проблемы в архитектурную. Поскольку страничный кеш единый на весь узел, атакующий, получивший контроль над одним контейнером, может через ту же четырёхбайтовую запись повредить кеш бинарников, используемых другими контейнерами или самим хостом. Это уже не просто повышение привилегий, а полноценный примитив побега из контейнера и компрометации мультитенантного узла.
Особенно уязвимы оказались публичные CI/CD-раннеры, где сборочные задания приходят из открытых репозиториев и регулярно содержат код от неизвестных авторов, а также платформы для запуска ИИ-агентов и серверлесс-функций, исполняющих чужой код в общей среде. Cloudflare в своём отчёте о реагировании на инцидент сообщил, что благодаря раннему переходу на ядро 6.12 LTS большая часть инфраструктуры компании оказалась защищённой ещё до публичного раскрытия, но подобным запасом прочности располагают далеко не все.
Почему открытие сравнивают с Dirty Cow, но считают опаснее
Сравнение с Dirty Cow напрашивается само собой, поскольку обе уязвимости касаются работы с памятью и обе позволяют получить root. Но различия принципиальны. Dirty Cow требовал многократных попыток, страдал от гонок и иногда укладывал систему в синий экран. Dirty Pipe был более стабилен, но требовал точной версии ядра и тонкой работы с буферами каналов. Copy Fail же демонстрирует пугающую универсальность.
Среди характеристик, делающих новую уязвимость особенно опасной, исследователи выделяют:
- Детерминированность срабатывания без гонок и без зависимости от тайминга;
- Портируемость одного и того же эксплоита между всеми основными дистрибутивами без перекомпиляции;
- Минимальный размер полезной нагрузки в 732 байта на чистом Python;
- Использование исключительно стандартных системных вызовов socket, setsockopt, splice, sendmsg и recvmsg, что делает обнаружение по сигнатурам затруднительным;
- Скрытность за счёт обхода обычного пути записи через VFS, из-за чего файлы на диске остаются нетронутыми, а целостность не нарушается.
Дополнительно ситуацию обостряет история обнаружения. По данным разработчиков из Xint, баг был найден их собственной системой автоматизированного анализа примерно за час работы. То есть инструменты на основе ИИ-помощников всё активнее вторгаются в нишу, которую раньше занимали только опытные исследователи безопасности, и порог входа в нахождение тяжёлых уязвимостей в ядре заметно снижается.
Что делать прямо сейчас и какие меры реально работают
Главное и единственно правильное долгосрочное решение - обновление ядра до версии с патчем (мейнлайн-коммит a664bf3d603d или вышестоящие сборки 6.18.22 и 6.19.12). Многие крупные дистрибутивы выпустили исправленные пакеты в течение нескольких дней после раскрытия, остальные подтягиваются по мере готовности. Cloudflare, как уже упоминалось, оказался защищён за счёт ранней миграции на свежий LTS, и эта история наглядно показывает ценность дисциплинированного обновления ядерного стека.
Если оперативное обновление невозможно, рекомендуется временная мера в виде отключения уязвимого модуля. CERT-EU предлагает создать файл /etc/modprobe.d/disable-algif.conf со строкой "install algif_aead /bin/false" и затем выгрузить модуль командой rmmod algif_aead. Это рабочий обходной путь, который не затрагивает большинство стандартных криптографических операций. Не страдают dm-crypt и LUKS, не ломаются kTLS, IPsec, OpenSSL, GnuTLS, NSS и SSH. Под удар попадают только приложения, которые явно используют движок afalg или напрямую открывают AEAD-сокеты через AF_ALG, что встречается достаточно редко.
Для оценки риска на конкретной системе можно посмотреть, кто из процессов сейчас держит сокеты этого семейства, командой lsof с фильтром по AF_ALG. Дополнительной защитой служат правильно настроенные мандатные механизмы контроля доступа. SELinux и AppArmor способны заблокировать создание AF_ALG-сокетов для процессов, которым они не нужны, но для этого политики должны быть достаточно строгими, что в реальной жизни выполняется не всегда.
Защитники в облачных средах получили от вендоров готовые правила обнаружения. Sysdig выкатил поведенческое правило для Falco, отслеживающее подозрительное создание AF_ALG-сокетов типа SOCK_SEQPACKET, который как раз и используется эксплоитом, тогда как легитимные пользователи криптографического API обычно работают через SOCK_DGRAM. Wiz и Palo Alto Networks предложили запросы для своих платформ, отслеживающие признаки повреждения кеша и аномалии в работе su.
Чему эта история учит индустрию о доверии к старому коду ядра
Copy Fail напоминает несколько важных вещей, о которых сообщество системных программистов обычно знает, но регулярно забывает. Первое - оптимизации, экономящие копирование памяти, исторически были и остаются источником самых злых уязвимостей. От Heartbleed до Spectre, от Dirty Cow до нынешнего сюжета почти все громкие истории так или иначе связаны с попытками не делать лишнюю работу с памятью. Граница между быстрым и безопасным проходит ровно по моменту, когда два разных потока данных начинают делить общий буфер.
Второе - криптографические подсистемы ядра, задумывавшиеся как удобный сервис для пользовательского пространства, со временем превратились в обширную и слабо изученную поверхность атаки. AF_ALG задумывался как способ дать приложениям доступ к аппаратному ускорению шифрования без необходимости разбираться с драйверами. Сегодня же этот интерфейс представляет собой готовый плацдарм для самых разных эксплуатационных техник, и многие администраторы вообще не подозревают о его существовании на своих серверах.
Третье - современные ИИ-инструменты для статического и динамического анализа кода уже приносят атакующим примерно столько же пользы, сколько защитникам. История о том, как баг был обнаружен автоматизированной системой за час, должна заставить владельцев крупных кодовых баз задуматься о собственных программах внутреннего аудита с применением похожих средств. Иначе разрыв во времени между нахождением уязвимости злоумышленником и её закрытием разработчиком будет только расти.
И наконец, четвёртое и самое практическое. Дисциплина обновления ядра в продакшене перестала быть вопросом гигиены и стала вопросом выживания. Те организации, которые поддерживают свежие LTS-сборки и имеют отработанный процесс быстрого выкатывания патчей, проходят подобные истории с лёгкой нервной дрожью. Те, у кого ядра не обновлялись годами, рискуют узнать о факте взлома уже постфактум, по странным записям в auth.log или вообще по их отсутствию там, где они должны были быть. Copy Fail показал, что эпоха долгоиграющих уязвимостей в фундаменте свободного программного обеспечения не закончена, и расслабляться рано.
Канал сайта в Telegram
Канал сайта на YouTube