Copy Fail CVE-2026-31431: почему эту уязвимость ядра Linux нельзя игнорировать и как защититься прямо сейчас

29 апреля 2026 года была публично раскрыта уязвимость CVE-2026-31431, получившая имя «Copy Fail». В отличие от десятков других локальных уязвимостей ядра Linux, которые требуют сложных подготовок или условий гонки, Copy Fail — это прямолинейная логическая ошибка: один и тот же 732-байтный Python-скрипт без модификаций за секунду поднимает привилегии до root на Ubuntu, RHEL, SUSE, Amazon Linux, Debian — практически на любом дистрибутиве, выпущенном с 2017 года. Уязвимость уже активно обсуждается в бюллетенях CERT-EU, Канадского центра кибербезопасности и других национальных агентств. Массовые патчи от вендоров на момент раскрытия отсутствуют, поэтому первоочередная задача каждого администратора — временное отключение уязвимого модуля algif_aead.

Техническая суть: откуда берутся 4 байта для root-доступа

Copy Fail относится к классу ошибок «некорректная передача ресурсов между доменами безопасности» (CWE-669). Корень проблемы — в оптимизации, внесённой в июле 2017 года коммитом 72548b093ee3 в подсистему algif_aead (AEAD-интерфейс пользовательского крипто-API AF_ALG). Эта оптимизация позволяла размещать страницы страничного кэша (page cache) непосредственно в целевом scatterlist, доступном для записи.

Используя системный вызов splice() в связке с AF_ALG-сокетом, злоумышленник может выполнить контролируемую 4-байтную запись в любую страницу страничного кэша, соответствующую файлу, доступному хотя бы на чтение. Целью обычно становится setuid-бинарник, например /usr/bin/su: модификация его образа в памяти позволяет получить root-оболочку без каких-либо изменений на диске.

Примечательно, что запись минует уровень виртуальной файловой системы (VFS), ничего не попадает на диск и не вызывает уведомлений inotify. После перезагрузки, когда страничный кэш заново заполняется с диска, следы атаки исчезают полностью. Это делает эксплойт чрезвычайно сложным для обнаружения традиционными средствами контроля целостности.

Исправление, принятое в мейнлайн-ядро 1 апреля 2026 года (коммит a664bf3d603d), откатывает ту самую оптимизацию 2017 года, восстанавливая разделение scatterlist'ов для источника и назначения.

Масштаб угрозы: кто затронут

Исследователи из Theori/Xint подтвердили успешную эксплуатацию на следующих дистрибутивах:

Дистрибутив	Проверенная версия ядра
Ubuntu 24.04 LTS	6.17.0-1007-aws
Amazon Linux 2023	6.18.8-9.213.amzn2023
RHEL 10.1	6.12.0-124.45.1.el10_1
SUSE 16	6.12.0-160000.9-default

Неявно затронуты все дистрибутивы, использующие ядро в диапазоне от 4.14 до 6.18.22 (не включительно), а также ветки 6.19.x до версии 6.19.12.

Особую опасность уязвимость представляет для сред с разделяемым ядром — Kubernetes-кластеров, CI/CD-раннеров, серверов виртуализации, облачных SaaS-платформ, исполняющих пользовательский код. Страничный кэш разделяется между всеми контейнерами на хосте, поэтому атака изнутри пода автоматически превращается в побег с контейнера и компрометацию всего узла.

Временная защита: отключение algif_aead

algif_aead. Для стандартных систем, где модуль компилируется отдельно, выполните:

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true

Эти команды создают правило, предотвращающее загрузку модуля в будущем, и немедленно выгружают его из текущей сессии.

Важно: для дистрибутивов семейства RHEL (RHEL, CentOS, AlmaLinux, CloudLinux), где модуль algif_aead часто встроен непосредственно в ядро (CONFIG_CRYPTO_USER_API_AEAD=y), данный метод не работает. Для таких систем используйте загрузочный параметр initcall_blacklist=algif_aead_init, добавляемый через grubby с последующей перезагрузкой.

Отключение algif_aead не затрагивает работу dm-crypt/LUKS, kTLS, IPsec/XFRM, SSH и стандартных сборок OpenSSL/GnuTLS/NSS. Единственное, что может перестать работать — это приложения, явно использующие AF_ALG-сокеты (например, OpenSSL с включённым движком afalg).

Постоянное исправление: обновление ядра

Как только ваш вендор выпустит патч, необходимо установить обновлённое ядро и перезагрузить систему. Фиксированные версии:

6.18.22 и выше для ветки 6.18.x
6.19.12 и выше для ветки 6.19.x
7.0 и выше для новых ядер

После установки патча отмените временное отключение модуля, удалив созданный ранее файл /etc/modprobe.d/disable-algif.conf или убрав параметр initcall_blacklist из загрузчика.

Защита контейнерных сред и CI/CD

Для изоляции ненадёжных рабочих нагрузок (поды Kubernetes, CI-раннеры, песочницы) рекомендуется дополнительно заблокировать создание AF_ALG-сокетов через seccomp-профили, независимо от наличия патча. Это страхует от будущих уязвимостей этого же класса.

В Kubernetes это достигается настройкой seccomp-профиля через securityContext пода; в Docker — через параметр --security-opt seccomp=<профиль>. Пример правила для seccomp-профиля, запрещающего AF_ALG:

{
  "architectures": ["SCMP_ARCH_X86_64"],
  "syscalls": [
    {
      "names": ["socket"],
      "action": "ERRNO",
      "args": [
        {
          "index": 0,
          "value": 38,
          "op": "SCMP_CMP_EQ"
        }
      ]
    }
  ]
}

Здесь 38 — это значение константы AF_ALG для архитектуры x86_64.

Заключение

Copy Fail (CVE-2026-31431) — одна из наиболее опасных локальных уязвимостей ядра Linux за последние годы. Её отличают абсолютная надёжность (100% успех с первой попытки), широчайший охват систем (все дистрибутивы с 2017 года), минимальный размер эксплойта и скрытность — следы атаки исчезают после перезагрузки. В сочетании с удалённым выполнением кода или компрометацией учётной записи обычного пользователя эта уязвимость открывает прямой путь к полному захвату сервера.

Приоритет действий:

Немедленно отключить algif_aead на всех затронутых системах.
В приоритетном порядке защитить Kubernetes-узлы, CI/CD-раннеры и системы с разделяемым ядром.
Отслеживать выпуск патчей вашим вендором и установить их, как только они станут доступны.
Настроить seccomp-блокировку AF_ALG для контейнерных сред.