Уязвимость Copy Fail в Linux: root-доступ на сборках с 2017 года

По состоянию на 5 мая 2026 года история с Copy Fail выглядит не как редкий баг для специалистов по ядру, а как очень практичная уязвимость для любой инфраструктуры, где непривилегированный код запускается рядом с общим Linux-ядром. CVE-2026-31431 даёт локальное повышение привилегий до root, затрагивает широкий пласт дистрибутивов и уже попала в каталог CISA Known Exploited Vulnerabilities с дедлайном на устранение до 15 мая 2026 года.

Ключевая оговорка сразу: это не удалённый взлом сам по себе и не очередной повод писать, что «все Linux уже скомпрометированы». Для эксплуатации нужен локальный запуск кода от непривилегированного пользователя. Но именно поэтому Copy Fail особенно опасна для Kubernetes-кластеров, self-hosted CI, shared Linux-hosts, jump-серверов и облачных сервисов, которые исполняют пользовательский код.

От обычного пересказа CVE этот кейс отличает сразу несколько вещей. Исследователи Xint и Theori говорят о маленьком и переносимом PoC, Microsoft пишет о высоком риске для облачных сред и контейнеров, Canonical уже выпустила временную меру через kmod, а SUSE отдельно предупреждает о риске для Kubernetes-сред. Это уже не абстрактная «уязвимость в ядре», а класс инфраструктурного риска, который надо читать через призму общего ядра и открытой инфраструктуры.

Что произошло

Публичное имя уязвимости — Copy Fail, идентификатор — CVE-2026-31431. По описанию Microsoft Security, речь идёт об опасной локальной LPE в криптографической подсистеме ядра Linux. Xint уточняет, что баг живёт в связке authencesn, AF_ALG и splice() и позволяет сделать контролируемую 4-байтную запись в page cache любого читаемого файла.

Это важно не только технически, но и операционно. Повреждается не файл на диске, а его версия в памяти. Поэтому обычная проверка целостности по контрольной сумме файла может ничего не заметить, а исполняемый setuid-бинарник вроде /usr/bin/su уже будет читаться ядром в испорченном виде. Отсюда и неприятная комбинация из надёжности, скрытности и переносимости между дистрибутивами.

Почему Copy Fail неприятнее типичной локальной LPE

У Linux уже были громкие локальные уязвимости вроде Dirty COW и Dirty Pipe, но у Copy Fail другой профиль риска. SUSE прямо пишет, что здесь нет сложной гонки, а Xint подчёркивает ту же мысль: это прямая логическая ошибка, а не хрупкий эксплойт с привязкой к версии и серией попыток до удачного попадания.

По данным copy.fail, один и тот же PoC проверен на Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1 и SUSE 16. Microsoft добавляет, что проблема затрагивает практически все Linux-дистрибутивы с уязвимыми ядрами, включая Debian, Fedora и Arch, пока не установлен патч. Для администраторов это означает неприятную вещь: здесь нельзя успокаивать себя тем, что «наш дистрибутив слишком особенный».

Вторая проблема — скрытность. Xint пишет, что ядро не помечает повреждённую страницу как dirty для writeback, а SUSE отдельно указывает: после перезагрузки следы исчезают, а обычные integrity checks по файлу на диске могут ничего не поймать. Для IR-команд это плохая новость: индикаторы могут быть слабее, чем у более шумных локальных эксплойтов.

Как работает баг без эксплуатационной романтики

На высоком уровне картина такая. AF_ALG открывает userspace-доступ к криптографической подсистеме ядра. splice() умеет передавать данные через pipe без обычного копирования, сохраняя ссылки на page cache. Из-за неудачной оптимизации 2017 года модуль algif_aead начал работать in-place в сценарии, где этого делать не стоило. В результате страница из page cache оказывалась внутри writable scatterlist, а одна логическая ошибка в authencesn превращала это в контролируемую запись на 4 байта.

Практический смысл здесь важнее конкретной функции: непривилегированный пользователь может повредить в памяти читаемый файл, который потом исполняется с повышенными правами. Microsoft, Xint и SUSE сходятся в одном: этого достаточно, чтобы получить root, не трогая сеть и не модифицируя сам файл на диске.

Исправление тоже показательно. Oracle и NVD ссылаются на commit a664bf3d603d, который по сути откатывает in-place design в algif_aead к out-of-place operation. То есть корень проблемы оказался не в «магической криптографии», а в инженерном решении, которое годами выглядело безопасной оптимизацией.

Где риск реально высокий

Если смотреть не на CVSS, а на реальные модели эксплуатации, Copy Fail бьёт прежде всего по тем средам, где недоверенная нагрузка и общее ядро встречаются каждый день.

• Multi-tenant Linux hosts. По copy.fail это shared dev boxes, build servers и jump hosts: любой пользователь с локальным кодом может стать root.
• Kubernetes и контейнерные кластеры. И Microsoft, и copy.fail, и SUSE указывают на общую page cache и общий kernel boundary: foothold внутри pod может перерасти в компрометацию node.
• CI/CD runners и build farms. Self-hosted GitHub Actions, GitLab Runner и Jenkins особенно неприятны, потому что там часто выполняется чужой код из pull request.
• Cloud SaaS с исполнением пользовательского кода. Notebook-hosting, agent sandboxes, serverless-like среды и внутренние automation-платформы тоже попадают в красную зону.

Для обычных single-tenant серверов риск ниже, но не нулевой. Microsoft прямо пишет, что уязвимость становится особенно опасной в цепочке после initial access: SSH-доступа, foothold внутри контейнера или вредоносного CI job. То есть Copy Fail — не замена первой стадии атаки, а очень сильный второй ход.

Что уже сделали Ubuntu, SUSE, Oracle и Red Hat

По состоянию на 5 мая 2026 года у разных вендоров разный статус ремедиации. И это как раз тот случай, когда нельзя писать «патч уже вышел» без уточнений.

Любопытная деталь у Canonical: 30 апреля компания отдельно писала, что для container deployments публичного PoC на тот момент ещё не было. При этом Xint и copy.fail уже прямо называли баг container escape primitive. Противоречия здесь нет. Один источник осторожно говорит о публичном пути эксплуатации в конкретном сценарии, другой — о классе воздействия. Для редакционной точности лучше держать формулировку так: уязвимость сама по себе локальная, но её архитектурный риск для контейнеров и Kubernetes подтверждён несколькими вендорами и исследователями.

Что делать администраторам прямо сейчас

1. Проверить, где у вас вообще исполняется непривилегированный код на общем kernel: CI runners, shared bastion hosts, Kubernetes nodes, internal sandboxes, notebook-среды.
2. Сверить статус дистрибутива не по новостям, а по vendor advisory: Ubuntu, SUSE, Oracle, Red Hat или другой ваш поставщик.
3. Если vendor kernel fix уже доступен, ставить именно его, а не ограничиваться обсуждением CVE в backlog.
4. Если патч ещё не установлен, использовать временную mitigation из vendor guidance: блокировку затронутого модуля или ограничение создания AF_ALG-сокетов для недоверенных workloads.
5. Относиться к любому container foothold как к потенциальному пути к host compromise, пока node не переведён на исправленное ядро.

Отдельно стоит учесть regression risk. Canonical предупреждает, что отключение модуля может задеть приложения, завязанные на hardware-accelerated cryptography, а copy.fail уточняет: для большинства систем эффект будет незаметен, но специфические userspace-конфигурации с AF_ALG всё же бывают. Значит, задача не сводится к одной команде «выключить и забыть»; нужен инвентарь и короткая проверка зависимостей.

Почему этот кейс важен не только для Linux-безопасности

У Copy Fail есть ещё один слой, который особенно важен для Toolarium. Xint пишет, что уязвимость нашли примерно за час сканирования подсистемы Linux crypto/, а Microsoft описывает её как угрозу для облачных и Kubernetes-сред. Вместе это даёт простой вывод: глубокие логические ошибки в низкоуровневом open-source коде становятся дешевле для поиска, а значит дороже для инфраструктуры, которая слишком полагается на «достаточно зрелое ядро».

Это стоит читать рядом с нашим материалом про правила для ИИ-кода в Linux kernel. Там спор шёл о качестве изменений и governance, здесь мы видим цену одной неудачной оптимизации, дожившей почти девять лет. Сюда же логично поставить и N-Day-Bench о том, как LLM ищут реальные уязвимости: если поиск глубоких багов ускоряется, окно между latent flaw и operational impact сокращается.

А для команд, которые воспринимают безопасность только как perimeter, полезен ещё один соседний кейс — компрометация Bitwarden CLI на npm. Там история была про supply chain, здесь про kernel logic flaw, но итоговый вопрос один и тот же: что происходит, когда атакующий получает даже небольшой foothold внутри инженерного контура.

Главный вывод

Copy Fail — не самый зрелищный Linux-баг последних лет, но один из самых показательных. Он не обещает «взлом по сети в один клик», зато очень хорошо показывает цену shared kernel в 2026 году. Если непривилегированный код уже оказался на хосте, в контейнере или на CI-runner, локальная LPE такого класса быстро превращается в инфраструктурную проблему, а не в баг для баг-трекера.

Поэтому правильная реакция на Copy Fail — не спор о том, «насколько это remote», а быстрая инвентаризация, исправления по рекомендациям поставщика и жёсткий приоритет для сред, где чужой код исполняется рядом с общим ядром. Именно там CVE-2026-31431 бьёт сильнее всего.

Источники и дата проверки

• copy.fail — публичная страница disclosure и mitigation, проверено 5 мая 2026 года.
• Xint: Copy Fail: 732 Bytes to Root on Every Major Linux Distributions, опубликовано 29 апреля 2026 года, проверено 5 мая 2026 года.
• Ubuntu: Fixes available for CVE-2026-31431, опубликовано 30 апреля 2026 года, проверено 5 мая 2026 года.
• Microsoft Security Blog: CVE-2026-31431, опубликовано 1 мая 2026 года, проверено 5 мая 2026 года.
• SUSE responds to the copy.fail vulnerability, обновлено 3 мая 2026 года, проверено 5 мая 2026 года.
• Oracle Linux CVE page, проверено 5 мая 2026 года.
• NVD: CVE-2026-31431, проверено 5 мая 2026 года.
• Red Hat KB: Is my RHEL system vulnerable to the Copy Fail flaw?, обновлено 5 мая 2026 года, проверено 5 мая 2026 года.

Читайте также

• Linux kernel AI-generated code: правила для ИИ-кода
• N-Day-Bench: как LLM ищут реальные уязвимости в коде
• Компрометация Bitwarden CLI на npm: кража SSH-ключей