CVE-2026-31431 (Copy Fail): уязвимость ядра Linux — кому угрожает и как устранить

CVE-2026-31431 (Copy Fail) — уязвимость ядра Linux, позволяющая локальному пользователю получить root-права за считанные секунды без гонок, ретраев и краш-окон. Эксплойт умещается в 732 байта Python-кода и работает на всех основных дистрибутивах с 2017 года.

Уязвимы Ubuntu, RHEL, SUSE, Amazon Linux, а также российские Astra Linux, РЕД ОС и AltLinux. Мы разобрали механизм атаки от перехвата страничного кэша до подмены setuid-бинарника и подготовили пошаговую инструкцию по проверке и устранению.

CVE-2026-31431 — это логическая ошибка в криптографическом шаблоне authencesn ядра Linux, обнаруженная исследовательской группой Xint Code. Уязвимость позволяет непривилегированному локальному пользователю выполнить контролируемую 4-байтную запись в страничный кэш любого доступного для чтения файла. Файл на диске остаётся неизменным, но ядро использует кэшированную в памяти версию — именно её читают read(), mmap() и execve().

Название Copy Fail отражает суть: механизм передачи данных между файловыми дескрипторами через splice() не дублирует страницы, а передаёт ссылки. Когда страничный кэш файла попадает в scatterlist криптографической операции как часть выходного буфера, алгоритм authencesn записывает 4 байта за пределы легитимной области вывода — прямо в кэшированную страницу целевого файла. Стандартные инструменты проверки целостности по контрольным суммам диска угрозу не обнаруживают.

В отличие от Dirty Cow (CVE-2016-5195), требовавшей выигрыша гонки в подсистеме VM и часто вызывавшей крах системы, Copy Fail срабатывает детерминированно — без гонок, ретраев и окон нестабильности. Dirty Pipe (CVE-2022-0847) был версионно-специфичен и требовал точной манипуляции буферами каналов. Copy Fail — прямолинейный логический дефект, работающий на всех архитектурах без подбора смещений и перекомпиляции.

Ключевые характеристики Copy Fail: переносимость — один скрипт на всех протестированных дистрибутивах (Ubuntu, RHEL, SUSE, Amazon Linux) без модификаций; компактность — 732 байта Python-кода со стандартными библиотеками (os, socket, zlib); скрытность — запись идёт в обход обычного пути VFS, страница не помечается ядром как «грязная»; межконтейнерность — страничный кэш разделяется между контейнерами на хосте, что делает уязвимость вектором выхода за пределы контейнера.

Уязвимости подвержены все основные дистрибутивы Linux, выпущенные с 2017 года. Именно тогда патч 72548b093ee3 оптимизировал algif_aead.c для выполнения AEAD-операций «на месте» (in-place). До этого момента страничный кэш находился в scatterlist источника (только чтение), и запись authencesn уходила в пользовательский буфер — уязвимости не существовало. Хронология создания проблемы: авторы authencesn (2011) использовали вызывающий буфер как черновик; разработчики AF_ALG (2015) добавили splice()-путь, но использовали раздельные scatterlist; оптимизация 2017 года объединила src и dst — и три безопасных по отдельности решения создали уязвимость.

Среди зарубежных дистрибутивов подтверждена уязвимость всех LTS-релизов Ubuntu с 16.04, Red Hat Enterprise Linux 7/8/9, SUSE Linux Enterprise Server 12/15 и Amazon Linux 2. Эксплойт проверен исследователями на всех четырёх платформах — работает стабильно без модификаций. Единственное требование: Python 3.10+ для os.splice. Никаких скомпилированных нагрузок и внешних зависимостей.

Российские операционные системы в зоне риска. Astra Linux Special Edition (релизы 1.6, 1.7) использует ядро 4.15/5.4/5.10 с модулем algif_aead. РЕД ОС (7.3 на ядре 5.10, версия 8 на ядре 6.1) и AltLinux (ветки p9, p10, p11) также включают проблемную комбинацию. Мы проверили типовые конфигурации ядра в этих ОС: CONFIG_AF_ALG либо в статусе =y (вкомпилирован), либо =m (доступен для загрузки). Отключение AF_ALG на уровне конфигурации — исключение, а не правило.

CVE-2026-31431 не зависит от архитектуры процессора — x86_64, ARM64, aarch64 и другие платформы затронуты одинаково. Страничный кэш реализован единообразно на всех архитектурах, а код authencesn и algif_aead написан на C без ассемблерных вставок. Любой процессор, на котором работает Linux, потенциально уязвим.

Не все системы находятся под непосредственной угрозой. Если ваша организация использует ядро, собранное без поддержки AF_ALG (CONFIG_AF_ALG=n), уязвимость неэксплуатируема. Проверить конфигурацию: zgrep CONFIG_AF_ALG /proc/config.gz или grep CONFIG_AF_ALG /boot/config-$(uname -r). Значение =m или =y означает доступность интерфейса. Отсутствие записи (CONFIG_AF_ALG is not set) — система неуязвима.

Системы с ядрами, собранными до 2017 года (ветки младше 4.9), не подвержены уязвимости — оптимизация in-place для algif_aead в них отсутствует, а значит страничный кэш никогда не попадает в выходной scatterlist. Однако такие ядра давно не получают обновлений безопасности и содержат десятки других известных уязвимостей. Эксплуатировать систему на ядре 3.x или 4.4 в 2026 году — более серьёзный риск, чем CVE-2026-31431.

Для оценки реального риска учитывайте модель угроз. Атака требует локального доступа — непривилегированной учётной записи на целевом хосте. Системы, доступные только по SSH с ключевой аутентификацией для доверенных администраторов, имеют существенно меньшую поверхность атаки. Но если на сервере работают многопользовательские сервисы (хостинг, CI/CD-раннеры, терминальные серверы, учебные среды), риск высок — любой студент, стажёр или клиент хостинга с шелл-доступом может получить root.

Для контейнерных сред важно понимать: пространства имён не защищают. Страничный кэш — ресурс уровня ядра, разделяемый всеми процессами на хосте. Даже если атакующий заперт в контейнере с минимальными capabilities, он может модифицировать страничный кэш setuid-бинарника на хосте и получить root за пределами контейнера. Подробный разбор этого вектора — во второй части отчёта Xint Code о контейнерном побеге.

Цепочка CVE-2026-31431 соединяет три независимых механизма ядра Linux: сокеты AF_ALG, системный вызов splice() и криптографический шаблон authencesn. Каждый компонент по отдельности корректен — проблема возникает исключительно на их пересечении. Понимание этого пересечения критично для грамотного выбора мер защиты.

Компонент 1: AF_ALG. Это тип сокета, предоставляющий криптографическую подсистему ядра непривилегированным пользовательским процессам. Открыв сокет, привязав его к шаблону AEAD — например, authencesn(hmac(sha256),cbc(aes)) — и установив ключ, пользователь может выполнять шифрование и расшифрование произвольных данных. Никаких привилегий не требуется: AF_ALG доступен любому процессу по умолчанию. Это фундаментальное проектное решение, не баг.

Компонент 2: splice(). Системный вызов splice() передаёт данные между файловыми дескрипторами и каналами без копирования — страницы страничного кэша передаются по ссылке. Когда пользователь направляет файл через splice() в канал, а затем в сокет AF_ALG, входной scatterlist сокета содержит прямые ссылки на физические страницы кэша ядра. Страницы не дублируются — scatterlist указывает на те же данные, которые read(), mmap() и execve() используют для доступа к файлу.

Компонент 3: оптимизация in-place. Патч 72548b093ee3 (2017) в algif_aead.c объединил входной и выходной scatterlist для экономии памяти. Теперь для расшифрования AAD и шифротекст копируются через memcpy_sglist из входного scatterlist в выходной буфер, но тег аутентификации (последние authsize байт входного scatterlist) не копируется. Вместо этого его scatterlist-записи цепляются к выходному scatterlist через sg_chain() — они по-прежнему указывают на страницы кэша целевого файла. После этого req->src и req->dst указывают на одну и ту же голову объединённой цепочки: буфер пользователя плюс страничный кэш.

Компонент 4: authencesn. Криптошаблон authencesn, разработанный для IPsec с поддержкой Extended Sequence Numbers (RFC 4303), использует выходной буфер вызывающего кода как рабочую область для перестановки байтов ESN. В crypto_authenc_esn_decrypt() вызов scatterwalk_map_and_copy записывает 4 байта seqno_lo на смещении assoclen + cryptlen — за пределы AEAD-тега, прямо в область, которая при in-place режиме указывает на страничный кэш. После завершения HMAC-проверки (которая завершается ошибкой, поскольку шифротекст поддельный) seqno_lo считывается обратно для восстановления AAD, но оригинальные байты на позиции записи не восстанавливаются. Четырёхбайтная запись сохраняется в страничном кэше.

Атакующий полностью контролирует три параметра: выбор файла (любой доступный на чтение), целевое смещение внутри файла (через комбинацию splice offset, splice length и assoclen) и записываемое значение (seqno_lo берётся из байт 4–7 AAD, переданного атакующим в sendmsg). Повторяя эту процедуру для каждого 4-байтного фрагмента, злоумышленник побайтово перезаписывает секцию .text setuid-бинарника, после чего execve() загружает модифицированную версию и передаёт управление шелл-коду.

CVE-2026-31431 диагностируется тремя командами без привилегий. Проверка начинается с определения версии ядра: uname -r. Все версии от 4.9 до актуальных (включая 6.x) потенциально уязвимы. Исправленные сборки появятся по мере выпуска патчей дистрибутивами — отслеживайте бюллетени безопасности вашего вендора и ФСТЭК России (bd.fstec.ru).

Далее проверьте доступность модуля algif_aead: lsmod | grep algif_aead. Если модуль загружен — интерфейс активен. Отсутствие в lsmod не гарантирует защиту: модуль может быть вкомпилирован статически. Проверьте modprobe --dry-run algif_aead — успешное выполнение означает, что модуль может быть загружен. Окончательный вердикт даёт команда: grep authencesn /proc/crypto. Наличие строки с authencesn в /proc/crypto означает, что шаблон зарегистрирован и доступен.

Мы подготовили безопасный однострочник для быстрой проверки — он не выполняет запись и пригоден для промышленных систем. Успешное выполнение без исключения означает доступность AF_ALG и authencesn — система уязвима. Ошибка Address family not supported или No such device говорит о недоступности интерфейса.

Для массовой проверки в организациях мы рекомендуем скрипт, обходящий все хосты по SSH и собирающий вывод трёх команд: версия ядра, наличие authencesn в /proc/crypto и статус модуля algif_aead. На 100 серверов такая проверка занимает менее 5 минут при параллельном запуске. В Ansible это делается модулем shell с register и последующей фильтрацией результатов по критерию наличия authencesn. Для сред с оркестрацией Kubernetes проверьте worker-узлы: именно они разделяют страничный кэш с контейнерами.

Единственный надёжный способ устранения CVE-2026-31431 — обновление ядра до версии с исправлением. На момент публикации патч проходит включение в mainline-ядро и процедуру бэкпортирования в стабильные ветки. Следите за обновлениями вашего дистрибутива. Ниже — проверенные команды для основных платформ.

Зарубежные дистрибутивы. Ubuntu/Debian: sudo apt update && sudo apt upgrade linux-image-generic -y && sudo reboot. RHEL/Rocky/AlmaLinux: sudo dnf update kernel -y && sudo reboot. SUSE: sudo zypper update kernel-default -y && sudo reboot. Amazon Linux 2: sudo yum update kernel -y && sudo reboot. После перезагрузки обязательно проверьте: uname -r должно показать новую версию ядра.

Российские дистрибутивы. Astra Linux: sudo apt update && sudo apt dist-upgrade -y && sudo reboot. Внимание: в Astra Linux Special Edition обновление ядра может потребовать повторной сертификации согласно приказу ФСТЭК — согласуйте процедуру с отделом ИБ. РЕД ОС: sudo dnf update kernel -y && sudo reboot. AltLinux: sudo apt-get update && sudo apt-get install kernel-image-std-def -y && sudo reboot. Для всех трёх дистрибутивов рекомендуем предварительно создать снапшот или резервную копию /boot на случай отката.

Временные меры (до установки обновления, снижают, но не исключают риск):
(1) Выгрузка модуля algif_aead: sudo rmmod algif_aead или sudo modprobe -r algif_aead. Работает только если модуль загружен динамически. Блокировка повторной загрузки: echo blacklist algif_aead | sudo tee /etc/modprobe.d/block-algif_aead.conf.
(2) Ограничение локального доступа: отключение неиспользуемых учётных записей, аудит SSH-доступа, двухфакторная аутентификация.
(3) Для контейнерных сред: сегментация хостов по уровню доверия — не размещайте контейнеры с ненадёжным кодом на тех же узлах, где работают критичные системные сервисы.
(4) Мониторинг использования AF_ALG: аудит через auditd или eBPF-программы, отслеживающие создание сокетов AF_ALG непривилегированными процессами.

График внедрения: интернет-доступные системы — немедленно (день 0); хосты с множеством локальных пользователей — день 1; внутренние серверы с ограниченным доступом — день 3; изолированные системы за межсетевым экраном — в рамках ближайшего регламентного окна, но не позднее 7 дней. Для систем, где перезагрузка невозможна без согласования, инициируйте процедуру немедленно — ожидание патча не отменяет необходимость перезагрузки после его установки.

CISA (Агентство кибербезопасности и инфраструктурной безопасности США) включила CVE-2026-31431 в каталог Known Exploited Vulnerabilities (KEV). Это решение имеет конкретные последствия для организаций любого масштаба. Согласно директиве BOD 22-01, все федеральные агентства США обязаны устранить уязвимость в установленный срок — стандартная практика KEV предполагает 14–21 день с момента включения в каталог. Для государственных учреждений, работающих с американскими партнёрами, это означает обязательное применение патча или компенсирующих мер.

Для частных организаций включение в KEV не накладывает прямых юридических обязательств, но является сильным сигналом приоритизации. CISA включает в каталог только уязвимости с подтверждённой эксплуатацией «в дикой природе» (in the wild). Факт включения Copy Fail в KEV означает три вещи: PoC-эксплойт общедоступен, активная эксплуатация подтверждена или неизбежна, а CISA рассматривает уязвимость как представляющую «значительный риск для федерального предприятия». Затягивание с обновлением превращает известную уязвимость в гарантированный вектор компрометации.

С точки зрения compliance, наличие неустранённой уязвимости из каталога KEV создаёт риски при аудитах. Стандарты PCI DSS (требование 6.1), ГОСТ Р 57580 и 152-ФЗ предписывают устранение критических уязвимостей в установленные сроки. Аудитор, обнаруживший неустранённую KEV-уязвимость со статусом «активно эксплуатируемая», с высокой вероятностью зафиксирует несоответствие. Мы рекомендуем включить CVE-2026-31431 в процесс управления уязвимостями с приоритетом Critical/CVSS 10 и отслеживать статус через бюллетени ФСТЭК России.

Практический план действий для руководителя IT-отдела, укладывающийся в типовой KEV-дедлайн (14 дней):
День 1 — инвентаризация всех Linux-хостов, проверка каждого описанным выше однострочником, формирование реестра уязвимых систем.
День 2–3 — применение временных мер (rmmod algif_aead, blacklist модуля) на интернет-доступных системах.
День 4–7 — тестирование обновления ядра на стенде, проверка совместимости с корпоративным ПО.
День 8–10 — плановое обновление продуктовых систем с предварительным уведомлением пользователей.
День 11–14 — верификация: повторная проверка всех хостов, подтверждение отсутствия authencesn в /proc/crypto, документирование в журнале управления инцидентами.

Ответы на часто задаваемые вопросы по теме статьи.