В ядре Linux закрыли дыру с CVSS 9,8: сервер можно захватить по сети без пароля

В ядре Linux исправлена уязвимость CVE-2026-98432 с оценкой CVSS 9,8 — максимальный уровень «критическая». Ошибка сидит в обработке входящих TCP-соединений по IPv4 и позволяет удалённому атакующему без учётных данных и без участия пользователя выполнить код в ядре. Затронуты все ядра начиная с версии 4.4, в которые не перенесено исправление, то есть практически любой ещё не обновлённый сервер Linux, который принимает TCP-соединения. Единственное полное решение — обновить ядро и перезагрузиться.

Срочности добавила Anthropic: 27 октября компания сообщила, что её модель Claude написала рабочий эксплойт, который на сервере с прослушивателем Multipath TCP (MPTCP) запускает произвольную команду от root; в демонстрации Anthropic на это ушло примерно 53 минуты попыток. Код эксплойта не публиковали, но с 29 октября по 4 ноября Red Hat и Ubuntu подняли уязвимости оценку до «критической», а команда Go предупредила, что программы на Go 1.24 и новее по умолчанию открывают именно такие прослушиватели.

• Уязвимы все ядра с 4.4 без исправления. Исправленные стабильные версии: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 и 7.3.
• Ошибка живёт в обычном IPv4 TCP: MPTCP — лишь условие известного эксплойта, а IPv6-соединения основной проблемой не затронуты.
• Патчи уже у Debian, Red Hat Enterprise Linux 8, 9 и 10, AlmaLinux 8 и SUSE; Ubuntu 26.10 исправлена по блогу Canonical. Для Ubuntu 22.04, 24.04 и 26.04 исправление лежит в тестовом репозитории -proposed, для 16.04–20.04 его пока нет.
• До обновления Red Hat и Ubuntu советуют правило nftables, которое отбрасывает IPv4-пакеты TCP с IP-опциями. Оно снижает риск, но не закрывает уязвимость.
• Отключение MPTCP через sysctl защищает только от описанного Anthropic сценария и требует перезапуска сервисов.

Какие версии исправлены по дистрибутивам

Дистрибутивы переносят исправление в свои ядра под собственными номерами, поэтому сверяться нужно с трекером дистрибутива, а не с версией апстрима. Состояние на 5 ноября 2026 года по бюллетеням вендоров (строки Ubuntu относятся к базовому пакету linux, а не к HWE и облачным ядрам; строка AlmaLinux 9 и 10 — по вторичному источнику):

Ubuntu — главный пробел. По трекеру Canonical пакет linux на 5 ноября помечен как уязвимый со статусом «в работе» во всех поддерживаемых выпусках, включая 26.10, хотя блог Canonical называет 26.10 исправленной; не затронут только базовый пакет 14.04. В блоге компании объясняют, что ядра для 22.04, 24.04 и 26.04 проходят проверку больше чем на 2 000 сертифицированных серверов и устройств, после чего попадут в обычный репозиторий updates. Тем, кто гоняет собственные приёмочные тесты ядра, Canonical предлагает уже сейчас поставить пакет из -proposed. SUSE при этом оценивает уязвимость по собственной шкале как «важную», а не критическую: в своём векторе CVSS компания считает сложность атаки высокой.

Ошибка срабатывает до того, как соединение дойдёт до приложения

Суть ошибки описана в коммите исправления «ipv4: free inet_opt and ireq_opt after an RCU grace period». Когда сервер принимает TCP-соединение, ядро сначала заводит лёгкий «запрос-сокет» для полуоткрытого рукопожатия, а после его завершения создаёт полноценный сокет. Если в IPv4-заголовке клиента были опции (например, Record Route или Timestamp), ядро сохраняет их, чтобы повторить в ответах.

Функция tcp_v4_syn_recv_sock() передавала сохранённые опции дочернему сокету без копирования. В это же время другой процессор мог обрабатывать повторно присланный SYN для того же запроса и собирать ответный SYN-ACK, читая те же опции. Если дочерний сокет к этому моменту уже уничтожен, память опций освобождалась обычным kfree(), и ip_options_build() читала освобождённую память — классический use-after-free. С коммита 2015 года запрос-сокеты обрабатываются без блокировки слушающего сокета, поэтому ничто не мешало такой гонке.

Вторая гонка того же рода — в миграции запрос-сокетов между слушателями (параметр net.ipv4.tcp_migrate_req=1 или BPF-программа с режимом прикрепления BPF_SK_REUSEPORT_SELECT_OR_MIGRATE): клон запроса и оригинал делили одни и те же опции, и освобождение клона могло выбить память из-под оригинала. Исправление заменяет оба kfree() на kfree_rcu(), который ждёт, пока все читатели закончат работу с памятью. IPv6 первой проблемой не затронут, потому что tcp_v6_syn_recv_sock() копирует опции; аналогичный случай миграции для IPv6 (он проявляется только с CALIPSO) авторы обещают закрыть отдельным патчем.

В пояснениях к оценке CVSS Linux CNA — группа разработчиков ядра, которая присваивает CVE, — подчёркивает: атакующий сам создаёт обе стороны гонки, сервер не проверяет ни полномочий, ни учётных данных, а уязвимый путь выполняется во время TCP-рукопожатия, до какой-либо аутентификации на уровне приложения. Последствия по той же оценке — утечка содержимого кучи ядра, повреждение памяти или падение системы.

MPTCP — не причина уязвимости, а условие известного эксплойта

Anthropic описала свой эксплойт в двух стадиях. Сначала гонка заставляет ядро прочитать подконтрольное атакующему поле длины и вернуть лишние байты; как только в них попадает указатель ядра, атакующий узнаёт раскладку адресного пространства и обходит KASLR. Затем та же ошибка используется для переполнения буфера и подмены указателя на колбэк адресом полезной нагрузки, заранее размещённой в памяти ядра через обычную функцию протокола. По словам Anthropic, проигранная гонка лишь обрывает рукопожатие и не роняет систему, поэтому попытки можно повторять бесконечно: в её демонстрации утечка указателя заняла 48 минут, выполнение команды — ещё 5.

Эксплойт Anthropic требует прослушивателя MPTCP — расширения TCP, которое позволяет одному соединению идти по нескольким путям. Отсюда волна советов отключать MPTCP. Команда Go 29 октября в рассылке golang-announce напомнила, что начиная с Go 1.24 программы на Go включают MPTCP для слушающих сокетов на Linux по умолчанию, и объяснила, как это отключить: переменной GODEBUG=multipathtcp=0 в окружении, строкой godebug multipathtcp=0 в go.mod или вызовами net.ListenConfig.SetMultipathTCP для отдельных сокетов. При этом, пишет Нил Патель из команды Go, «отключение MPTCP программа за программой — хрупкая мера. Случайно оставленный единственный прослушиватель MPTCP по-прежнему оставит систему уязвимой. Кроме того, это предполагает, что все рабочие эксплойты зависят от MPTCP. Мы настоятельно рекомендуем обновиться до исправленного ядра» (перевод редакции). Менять умолчание Go команда пока считает преждевременным; обсуждение идёт в issue 82717.

Red Hat в бюллетене RHSB-2026-016 идёт дальше: в RHEL MPTCP выключен по умолчанию, и такие системы всё равно уязвимы. Проверка ss -Mlnp, по словам компании, «не является тестом на подверженность уязвимости», а пустой список прослушивателей MPTCP «следует считать справочной информацией, а не гарантией». Red Hat 30 октября подняла оценку с «важной» (8,1) до «критической» (9,8), сославшись на отсутствие сетевых предусловий для атаки и риск серьёзной нестабильности системы.

По оценке Тревора Фаннина, основателя компании Atlas, которая ведёт подробный разбор уязвимости, в интернете, по подсчётам исследователей, на которых он ссылается, около 2,1 млн серверов принимают MPTCP-соединения на порту 443 (это не число уязвимых машин), а со 2 ноября исследователи фиксируют сканирование, похожее на поиск таких серверов. На GitHub, по его подсчёту, уже не меньше десяти репозиториев заявляют о коде, который воспроизводит гонку; в каталог CISA активно эксплуатируемых уязвимостей запись на 4 ноября не входила. Независимо эти наблюдения мы не проверяли.

Что делать: проверить версию, обновить, перезагрузить

Первым делом узнайте, какое ядро работает и какие пакеты установлены. Canonical в блоге приводит команды для Debian и Ubuntu; для RHEL, AlmaLinux и других RPM-дистрибутивов сработает rpm -q kernel. Запускать их нужно на хосте, а не внутри контейнера: контейнер использует ядро хоста, и обновление образа ничего не меняет.

        uname -r
dpkg -l 'linux-image*' | grep ^ii   # Debian, Ubuntu
rpm -q kernel                        # RHEL, AlmaLinux
    

Сравните номер с таблицей выше. Если установленное ядро новее запущенного, исправление не действует до перезагрузки — об этом напоминают и Canonical, и Red Hat. На Ubuntu 22.04, 24.04 и 26.04 исправленное ядро можно поставить из -proposed, если вы готовы взять на себя его проверку. Команда ниже рассчитана на ядро, установленное через метапакет linux-meta; после перезагрузки проверьте через uname -r, что запущена исправленная сборка:

        sudo add-apt-repository --component main --pocket proposed http://archive.ubuntu.com/ubuntu
sudo apt update
dpkg-query -W -f '${source:Package}\t${binary:Package}\n' | awk '$1 ~ "^linux-meta" { print $2 }' | xargs sudo apt install -t $(. /etc/os-release && echo $VERSION_CODENAME)-proposed --only-upgrade
sudo reboot
    

Пока обновления нет, Red Hat и Ubuntu предлагают одинаковое правило nftables: отбрасывать входящие IPv4-пакеты TCP, у которых длина IP-заголовка больше стандартных 20 байт, то есть пакеты с IP-опциями. Трафик без IPv4-опций обычно продолжает работать: опции TCP вроде временных меток и масштабирования окна живут в заголовке TCP и под правило не попадают, а вот соединения, которым нужны IPv4-опции, будут заблокированы. Правило действует в сетевом пространстве имён хоста и срабатывает сразу для новых и уже открытых соединений, перезапускать сервисы не нужно; контейнеры с отдельной сетью оно не покрывает.

        cat > cve-2026-98432.nft <<'EOF'
table inet cve_2026_98432 {
  chain input {
    type filter hook input priority -310; policy accept;
    ip protocol tcp ip hdrlength > 5 counter drop
  }
}
EOF
sudo nft --check --file cve-2026-98432.nft
sudo nft --file cve-2026-98432.nft
sudo nft list table inet cve_2026_98432
    

Если MPTCP вам не нужен, его можно выключить от root командой sysctl -w net.mptcp.enabled=0, но это действует только на сокеты, созданные после изменения, — работающие сервисы придётся перезапустить. Red Hat считает такую меру слабее фильтра пакетов: она убирает одну известную конфигурацию атаки, а не вход, который нужен ошибке. В первую очередь обновляйте хосты, которые принимают соединения из интернета, и ноды Kubernetes: по бюллетеню Red Hat, в OpenShift правило nftables на ноде действует только на трафик через хостовое пространство имён; фильтруется ли внешний трафик, перенаправленный к подам, зависит от конфигурации сети, а для трафика между подами временной меры пока нет.

За чем следить дальше

Главные открытые вопросы на 5 ноября: когда исправленные ядра Ubuntu LTS выйдут из -proposed в updates, появится ли обновление для 20.04 и старше, и когда Red Hat закроет уязвимость в RHEL CoreOS для OpenShift. Отдельный патч обещан и для аналогичной гонки в IPv6 с CALIPSO. Уязвимость — одна из серии, которую Anthropic нашла с помощью Claude: в том же отчёте описаны цепочки эксплойтов для Chrome, Safari, Android и Windows. О похожем эксперименте OpenAI, где, по данным OpenAI, её система подготовила 948 эксплойтов для повышения привилегий в Linux, мы писали отдельно. Освежить, как устроено TCP-рукопожатие, поможет наш разбор стека TCP/IP, а о сетевом программировании на Go — глава самоучителя.