Copy.Fail показывает, почему «локальные» баги Linux давно не локальные

Copy.Fail описывают как серьезное локальное повышение привилегий в ядре Linux. Важен не только сам баг. Важнее то, что он говорит о современной инфраструктуре: «локальный» атакующий уже может находиться внутри контейнера, CI-задачи, shared-хоста или машины разработчика.

В источнике со ссылкой на раскрытие Theori от 29 апреля 2026 года сказано, что рабочий proof of concept уже существует. Проблема описана как Linux kernel LPE, связанная с kernel crypto API через AF_ALG sockets и splice(). Заявленный эффект узкий, но опасный: запись по четыре байта за раз в page cache файла, которым атакующий не владеет.

Это различие важно. Сообщается, что файл на диске не меняется. Если такое описание верно для затронутых сред, мониторинг целостности по контрольным суммам может пропустить изменение: проверяемые байты на диске остаются прежними.

Что известно#

Источник описывает Copy.Fail как локальное повышение привилегий в ядре Linux, а не как атаку через браузер, буфер обмена или удаленный сетевой эксплойт.

Заявленный путь эксплуатации использует AF_ALG sockets и splice(). По данным источника, это позволяет писать в page cache файла без владения этим файлом. Там же сказано, что эксплойт без изменений работает в основных Linux-дистрибутивах, включая Ubuntu, RHEL, Debian, SUSE, Amazon Linux и Fedora.

Это сильные утверждения. Их стоит воспринимать как утверждения из указанного источника, пока они не подтверждены конкретным вендорским advisory, коммитом ядра или бюллетенем дистрибутива. Но практический вывод все равно понятен: если вы запускаете Linux-ядра в shared- или semi-shared-средах, такой баг нельзя списывать со счетов только потому, что ему нужно локальное выполнение кода.

Источник также говорит, что исправление попало в mainline 1 апреля, а дистрибутивы начали выкатывать обновленные ядра. Это создает привычное окно риска при патчинге: в mainline исправление уже есть, но не каждый production-флот успел протестировать и развернуть пакет ядра от своего дистрибутива.

Почему слово «локальный» сбивает с толку#

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

В 2026 году такая оценка ломается.

Локальное выполнение кода часто встроено в систему по дизайну. Контейнеры запускают код поверх общих ядер. CI/CD-системы выполняют код из веток, зависимостей, тестовых harness и иногда из недоверенных pull request. Shared-хостинг никуда не исчез. Kubernetes-узлы часто размещают нагрузки разных приложений или команд. Ноутбуки разработчиков запускают WSL2, контейнеры, инструменты сборки и локальные агенты.

Все эти среды могут дать атакующему первый шаг: какой-то способ выполнить код без root.

Надежный kernel LPE резко повышает ценность этого первого шага. Атакующему не нужно ломать каждую границу приложения. Он может целиться в границу ядра под ними. Если эта граница падает, изоляция контейнеров, разделение пользователей и предположения на уровне workload могут рухнуть на том же хосте.

Поэтому «локальный» не должен автоматически означать «низкий приоритет». Это означает, что атакующему нужна точка опоры. Во многих современных системах такие точки опоры не редкость.

Деталь с page cache важна#

Самая интересная техническая деталь в источнике — заявленное поведение page cache.

Если атакующий может изменить то, как файл виден через память, не меняя файл на диске, защитники теряют часть простых способов обнаружения. Инструменты, которые сравнивают сохраненные хэши файлов или следят за прямым изменением на диске, могут не увидеть то, что использует работающая система.

Источник называет AIDE, Tripwire и мониторинг на основе контрольных сумм примерами контролей, которые ничего не увидят, если файл на диске не изменился.

Это не делает мониторинг бесполезным. Это значит, что контроль, построенный вокруг одного предположения, может не сработать, когда атака живет ниже этого предположения. Проверки целостности файлов отвечают на вопрос: «Изменились ли байты файла на диске?» Они могут не ответить на другой вопрос: «Можно ли обмануть привилегированный процесс через состояние, опосредованное ядром?»

Для операторов это повод не считать один чистый отчет о целостности доказательством безопасности, если эксплуатация на уровне ядра стала правдоподобной.

Контейнеры и seccomp не решают все автоматически#

Источник говорит, что Kubernetes Pod Security Standards в профиле Restricted и стандартный RuntimeDefault seccomp profile не блокируют соответствующий syscall. Нужен custom seccomp profile.

Это важная операционная оговорка. Многие команды считают, что если workload контейнеризован и работает под restricted-политикой, поверхность атаки на ядро заметно сдержана. Иногда так и есть. Иногда опасный примитив все еще доступен.

Seccomp полезен ровно настолько, насколько точна примененная syscall-политика. Профиль по умолчанию не гарантирует защиту от нового пути эксплуатации ядра. Pod Security Standards тоже не заменяют полноценную систему смягчения kernel-эксплойтов. Они сокращают exposure, но не убирают проблему доверия к общему ядру.

Если ваш кластер запускает workload с разным уровнем доверия, состояние патчей ядра важнее формулировок workload-политики.

Чего не стоит утверждать сверх фактов#

В исходном материале есть сравнение Copy.Fail с другой заявленной проблемой Linux, которую называют Dirty Frag. Там же есть более широкие комментарии про embargo, сроки disclosure и провалы доверия.

Эти темы важны, но их не нужно склеивать в одну историю.

По предоставленному материалу Copy.Fail и Dirty Frag следует рассматривать как отдельные сообщения, пока первичный источник не установит техническую связь между ними. Сам источник отмечает путаницу вокруг терминов вроде broken embargo и «zero-day patch gap». Для Copy.Fail полезное утверждение такое: исправление уже было upstream, пока rollout в дистрибутивах еще шел. Для Dirty Frag процитированные комментарии описывают другую ситуацию: предполагаемо нарушенный disclosure и отсутствие патчей на момент раскрытия.

Эта статья о Copy.Fail. Не стоит выдавать факты о Dirty Frag за факты о Copy.Fail.

Также не стоит утверждать подтвержденную эксплуатацию in the wild, если первичный advisory этого не говорит. Рабочий proof of concept повышает риск. Но это не то же самое, что подтвержденная массовая эксплуатация.

Что проверить операторам#

Начните с инвентаризации ядер. Найдите exposed Linux kernels на серверах, Kubernetes-узлах, CI runners, build-машинах, shared-хостинге, рабочих станциях разработчиков и cloud images. Не ограничивайтесь системами, доступными из интернета.

Затем проверьте vendor advisories для своего дистрибутива. Исправления в mainline kernel не всегда напрямую сопоставляются с именами пакетов дистрибутива, backport-версиями или cloud images. Ориентируйтесь на advisory своего дистрибутива, а не только на upstream-номер версии.

Для container platforms проверьте, разделяют ли workload одни и те же узлы через границы доверия. Кластер, где работает одно семейство приложений, несет другой риск, чем кластер с недоверенными jobs, tenant workloads или произвольным build-кодом.

Практические проверки:

• Убедитесь, что ваш дистрибутив выпустил kernel update для Copy.Fail.
• В первую очередь займитесь shared Kubernetes nodes, CI/CD runners и multi-tenant hosts.
• Перезагрузите систему или примените live-patch, если это требуется; скачанный пакет ядра не защищает, пока новое ядро не активно.
• Проверьте custom seccomp options, если не можете сразу установить патч.
• Считайте чистый отчет checksum monitoring неполным доказательством для проблем такого класса.
• Следите за vendor guidance по обнаружению и смягчению именно для вашей сборки ядра.

Главный урок#

Copy.Fail — история про баг в ядре, но проблема шире и касается архитектуры. Современная инфраструктура часто продает изоляцию на границе контейнера, job или пользователя, продолжая делить одно ядро под ними.

Такой дизайн может быть эффективным и достаточно безопасным, пока граница ядра держится. Когда появляется надежное локальное повышение привилегий, каждый путь низкопривилегированного выполнения кода становится ценнее для атакующего.

Поэтому главный вопрос не «Это удаленная уязвимость?» Лучше спросить так: «Где мы разрешаем недоверенному или semi-trusted-коду выполняться на общем Linux-ядре?»

Именно эти системы нужно патчить первыми.