Об уязвимости

CVE-2026-31431, публично известная как Copy Fail, — это локальная уязвимость повышения привилегий в ядре Linux, связанная с модулем algif_aead, который реализует интерфейс AEAD криптографического API ядра в пользовательском пространстве через AF_ALG.

По сути, проблема позволяет локальному пользователю с низкими привилегиями использовать логическую ошибку в пути обработки памяти этой подсистемы и повысить воздействие до полной компрометации целостности системы. Оценка, опубликованная kernel.org и отражённая в NVD, составляет CVSS 7.8 с вектором AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, что означает, что атака требует локального выполнения, но оказывает высокое воздействие на конфиденциальность, целостность и доступность.

Когда она была внедрена и раскрыта

• Эксплуатируемая первопричина была внедрена в ядро в 2017 году, когда в algif_aead была добавлена оптимизация на месте.
• CVE была опубликована в NVD 22 апреля 2026 года.
• Более широкое публичное раскрытие проблемы под названием Copy Fail с публичным доказательством концепции произошло 29 апреля 2026 года.
• Основное исправление в вышестоящем репозитории было внесено 1 апреля 2026 года, до широкого раскрытия конечным пользователям.

Что она эксплуатирует

Согласно опубликованным техническим рекомендациям, недостаток основан на комбинации:

• интерфейса ядра AF_ALG
• модуля algif_aead
• оптимизации операций на месте, внедрённой в 2017 году
• связывания этого интерфейса с splice()

Практический результат — возможность локального процесса выполнить небольшую контролируемую запись в страницы, поддерживаемые page-cache, читаемых файлов. При благоприятных условиях этого достаточно, чтобы превратить ограниченную локальную точку опоры в повышение привилегий до root.

Как это влияет на компанию

Реальный риск заключается не просто в «работе на уязвимом ядре Linux», а в допуске низкодоверенного локального кода до этого пути ядра. В корпоративных средах это обычно означает более высокую подверженность на:

• многопользовательских серверах
• jump-хостах и бастионах
• CI/CD-раннерах
• контейнерных нагрузках, выполняющих недоверенный код
• кластерах Kubernetes
• виртуальных машинах, размещающих автоматизацию, агентов, плагины или сторонние задания

Если у злоумышленника уже есть некоторая форма локального выполнения, даже без root, эта CVE может стать следующим шагом к компрометации хоста. На практике это расширяет риск:

• полного захвата сервера
• модификации локальных бинарных файлов или артефактов
• кражи учётных данных, токенов и резидентных секретов
• бокового перемещения на другие активы
• саботажа конвейеров и цепочек сборки

Для чего используется модуль algif_aead

algif_aead является частью криптографического интерфейса ядра в пользовательском пространстве (AF_ALG). Он позволяет приложениям использовать криптографические примитивы ядра через сокеты, особенно операции AEAD (аутентифицированное шифрование со связанными данными).

Этот модуль обычно не является обязательным для большинства стандартных серверных нагрузок. Согласно рекомендациям по смягчению последствий, опубликованным CERT-EU, отключение algif_aead в качестве временной меры:

• не должно влиять на dm-crypt или LUKS
• не должно влиять на kTLS
• не должно влиять на IPsec/XFRM
• не должно влиять на OpenSSL, GnuTLS, NSS или SSH при стандартном использовании

С другой стороны, его отключение может повлиять на:

• приложения, явно настроенные на использование движка afalg
• программное обеспечение, открывающее сокеты AF_ALG напрямую
• пользовательские интеграции, использующие aead, skcipher или hash через криптографический API ядра

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

Операционное влияние отключения модуля

Блокировка модуля немедленно снижает подверженность, но сопряжена с компромиссами:

• приложения, зависящие от AF_ALG, могут не запуститься или потерять криптографическое ускорение на базе ядра
• пользовательские нагрузки могут выйти из строя только во время выполнения, а не при загрузке
• если модуль уже загружен, смягчение последствий завершается только после успешной выгрузки или перезагрузки

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

Рекомендуемое постоянное исправление

Внесение модуля в чёрный список — лишь временная мера. Постоянное исправление:

1. установите пропатченное ядро, предоставленное поставщиком дистрибутива
2. перезагрузите хост, чтобы новое ядро действительно загрузилось
3. убедитесь, что хост больше не сообщается как затронутый
4. только затем решите, следует ли оставить чёрный список модуля

Дополнительные рекомендуемые меры:

• приоритизируйте установку исправлений на хостах с локальными пользователями, контейнерами или выполнением недоверенного кода
• ограничьте создание сокетов AF_ALG с помощью seccomp в контейнерах и конвейерах, где это применимо
• проверьте, где явно используется afalg или криптографический API ядра
• ведите учёт версий ядра и ожидающих перезагрузок
• рассматривайте CI/CD-раннеры и узлы Kubernetes как высокоприоритетные

Что проверяет скрипт

Скрипт проверяет:

• имя хоста
• версию работающего ядра
• операционную систему через /etc/os-release
• наличие модуля algif_aead
• загружен ли модуль в данный момент
• заблокирован ли модуль правилом modprobe
• требует ли хост перезагрузки (/var/run/reboot-required)
• статус, сообщаемый Ubuntu Pro через pro fix CVE-2026-31431 --dry-run, если доступно

На основе этого возвращается одна из следующих классификаций:

• PATCHED_OR_NOT_AFFECTED
• LIKELY_NOT_VULNERABLE
• MITIGATED
• VULNERABLE_MODULE_LOADED
• POTENTIALLY_VULNERABLE
• UNKNOWN

Логика классификации

Кратко:

• Если инструментарий Ubuntu указывает, что хост не затронут или уже исправлен, статус становится PATCHED_OR_NOT_AFFECTED.
• Если модуль algif_aead не существует в текущем ядре, статус, как правило, LIKELY_NOT_VULNERABLE.
• Если модуль существует, но заблокирован и не загружен, статус становится MITIGATED.
• Если Ubuntu указывает, что хост затронут, и модуль загружен, статус становится VULNERABLE_MODULE_LOADED.
• Если модуль существует и может быть загружен, но состояние исправления не может быть подтверждено, статус становится POTENTIALLY_VULNERABLE.

Требования

• Bash
• modinfo
• modprobe
• lsmod
• awk
• grep
• hostname
• uname
• apt-get для --update
• sudo при запуске от имени пользователя, не являющегося root
• pro опционально, для обогащения анализа на Ubuntu

Использование

Если файл скрипта называется check_cve_2026_31431.sh:

Проверка по умолчанию

Пример вывода:

Вывод в формате JSON

Пример:

Этот вывод полезен для автоматизации, инвентаризации активов и конвейеров соответствия требованиям.

Смягчение последствий

Режим --mitigate создаёт файл:

Со следующим содержимым:

После этого скрипт пытается удалить модуль из памяти с помощью:

Использование:

Если пользователь не является root, скрипт попытается использовать sudo.

Обновление

Режим --update выполняет:

Использование:

Этот режим пытается обновить пакеты, связанные с ядром, в системах на основе Debian и Ubuntu. В других средах этот шаг может не применяться.

Справка

Вывод:

Важные ограничения

• Скрипт использует эвристики. Он не доказывает эксплуатацию; он оценивает подверженность и состояние смягчения последствий.
• Поля ubuntu_affected и fix_available зависят от наличия команды pro.
• Шаг --update использует шаблоны пакетов, ориентированные на Ubuntu и Debian, и может не охватывать все пользовательские ядра.
• В некоторых дистрибутивах модуль может существовать с поведением, отличающимся от ожидаемого скриптом.
• Блокировка модуля в некоторых средах может потребовать перезагрузки для гарантии согласованного состояния.

Рекомендуемый рабочий процесс

1. Запустите --check для оценки хоста.
2. Если модуль доступен и исправление не применено, запустите --mitigate.
3. Запустите --update или примените официальное обновление поставщика.
4. Перезагрузите хост, если требуется.
5. Запустите --check --json для проверки конечного состояния и сохранения доказательств.

Примечание

Для ясности публикации скрипт в идеале должен использовать описательное имя, например:

Авторы

Материал организован и опубликован с указанием авторства SEC17.

Официальный сайт:

• https://sec17.com