CVE-2026-98432: уязвимость TCP в Linux и защита серверов

Что такое CVE-2026-98432?

CVE-2026-98432 — уязвимость в ядре Linux, основе операционных систем Linux. Её официальное название — ipv4: free inet_opt and ireq_opt after an RCU grace period ^[1]. Идентификатор присвоила команда CVE ядра Linux, опубликовавшая запись 15 октября 2026 года ^[1]. В записи указана базовая оценка CVSS 3.1, равная 9,8, что соответствует уровню «критическая» ^[1].

Это ошибка типа use-after-free (использование после освобождения): программа продолжает обращаться к участку памяти после того, как он был освобождён, и в нём уже могут находиться другие данные. В данном случае ошибка находится в коде, обрабатывающем входящие запросы на установку IPv4 TCP-соединений ^[10]. Вектор CVSS — AV:N/AC:L/PR:N/UI:N. Это означает, что атака выполняется по сети, имеет низкую сложность и не требует ни привилегий, ни действий пользователя ^[1].

Ошибка существует начиная с Linux 4.4, куда она попала вместе с коммитом 079096f103fa ^[2]. Исправление, написанное Эриком Дюмазе (Eric Dumazet), было закоммичено 5 октября 2026 года и уже входит в основную ветку ядра ^[3]. Оно перенесено в поддерживаемые стабильные ветки ^[2][4].

Какие системы затронуты?

По данным Red Hat, уязвимость затрагивает любую систему с уязвимым ядром и включённой поддержкой IPv4 TCP. Наиболее непосредственно уязвимы системы, принимающие входящие TCP-соединения ^[6]. AlmaLinux рекомендует считать уязвимой любую систему, которая принимает IPv4 TCP-соединения из недоверенных сетей ^[10]. Основная проблема не затрагивает IPv6 ^[2].

Как работает уязвимость?

TCP-соединение начинается с рукопожатия. Клиент отправляет пакет SYN, сервер отвечает пакетом SYN-ACK, а клиент подтверждает соединение. Пакет SYN может содержать опции IPv4 — необязательные дополнительные поля в IP-заголовке. Два примера — Record Route и Timestamp ^[1].

Согласно описанию в ядре, функция tcp_v4_syn_recv_sock() передаёт сохранённые опции новому дочернему сокету, не копируя их ^[2]. Тем временем другое ядро процессора может обработать повторно переданный SYN для того же запроса и сформировать SYN-ACK, который читает эти опции ^[2]. Ничто не мешает освободить дочерний сокет, пока SYN-ACK ещё формируется. Его опции освобождаются обычным вызовом kfree(), поэтому ядро читает уже освобождённую память в ip_options_build() ^[2].

Второе, похожее состояние гонки возникает, когда включена миграция сокетов запросов — через net.ipv4.tcp_migrate_req=1 или через программу BPF reuseport ^[2]. Исправление заставляет оба пути освобождения дожидаться окончания льготного периода RCU, используя kfree_rcu() в inet_sock_destruct() и tcp_v4_reqsk_destructor() ^[2]. RCU (read-copy-update, «чтение-копирование-обновление») — механизм ядра, который откладывает освобождение памяти до тех пор, пока ни один читатель уже не может её использовать.

Что может сделать злоумышленник?

В примечаниях к оценке в записи CVE описаны три вида последствий ^[1]:

• Раскрытие информации: освобождённая память может быть занята другими данными, и её содержимое может попасть в SYN-ACK, отправляемый обратно злоумышленнику ^[1].
• Повреждение памяти: устаревшие значения длины и смещения могут направить запись ядра за пределы буфера с возможным нарушением потока управления ^[1].
• Сбои: повторно использованное значение длины может вызвать kernel panic, а ошибочные записи также способны обрушить ядро ^[1].

Red Hat добавляет, что для надёжного выполнения кода через эту чувствительную ко времени ошибку требуется точный контроль над кучей. Тем не менее компания оценивает ошибку как критическую, поскольку для неё нет сетевых предварительных условий и она может вызвать серьёзную нестабильность ^[7].

Что раскрыла Anthropic и какую роль играет MPTCP?

27 октября 2026 года команда Frontier Red Team компании Anthropic опубликовала обзор уязвимостей, найденных с помощью моделей Claude ^[4][11]. По поводу CVE-2026-98432 в нём говорится, что команда создала эксплойт, позволяющий удалённому злоумышленнику выполнять произвольные команды от имени root на Linux-серверах с прослушивающим сокетом Multipath TCP (MPTCP), без учётных данных и без действий пользователя ^[4]. MPTCP — расширение TCP, позволяющее одному соединению одновременно использовать несколько сетевых путей.

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

Обязателен ли MPTCP?

Нет, по данным проанализировавших уязвимость поставщиков. Red Hat заявляет, что MPTCP не является обязательным условием для этой уязвимости и что системы с отключённым MPTCP остаются уязвимыми ^[6]. Команда безопасности Go отмечает, что продемонстрированному эксплойту нужен прослушивающий сокет MPTCP, но сама ошибка не связана именно с MPTCP ^[5]. Go здесь важен потому, что начиная с Go 1.24 программы на Go по умолчанию включают MPTCP для прослушивающих сокетов в Linux ^[5].

По данным Akamai, Anthropic не опубликовала свой эксплойт для получения root, а 2 ноября 2026 года Akamai сообщила, что ей неизвестно о публичном работающем эксплойте ^[11].

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

Команда CVE ядра перечисляет следующие исправления в основной ветке разработки: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 и mainline 7.3 ^[2]. Однако большинство пользователей работает с ядром, собранным их дистрибутивом, у которого собственная нумерация версий. Сверяйтесь с бюллетенем своего дистрибутива, а не сравнивайте номера версий upstream.

Ситуация на 3 ноября 2026 года:

• Red Hat Enterprise Linux: исправленные ядра выпущены 1 ноября 2026 года для RHEL 8, 9 и 10. RHEL 6 и 7 указаны как незатронутые. Ядро реального времени RHEL 9 и образы узлов OpenShift по-прежнему значатся уязвимыми ^[7].
• Ubuntu: Ubuntu оценивает проблему как критическую. Её трекер показывает 26.10, 26.04 LTS, 24.04 LTS и 22.04 LTS как уязвимые с исправлениями в работе; 20.04, 18.04 и 16.04 также указаны как уязвимые, а 14.04 — как незатронутая ^[8].
• Debian: исправления доступны для Debian 12 bookworm (linux 6.1.190-1 и linux-6.12 6.12.113-1~deb12u1) и Debian 13 trixie (linux 6.12.113-1), а также для unstable ^[9].
• AlmaLinux: исправленные ядра для AlmaLinux 8, 9 и 10 находятся в рабочих репозиториях ^[10].
• Другие: по данным Akamai, к 30 октября 2026 года SUSE, Oracle Linux и Amazon Linux 2023 выпустили исправленные ядра для некоторых версий ^[11].

А как же телефоны на Android?

Android использует ядро Linux, однако в бюллетене безопасности Android, опубликованном 2 ноября 2026 года, CVE-2026-98432 не упоминается ^[13]. Владельцам телефонов следует устанавливать обновления безопасности по мере их выпуска производителем.

Как проверить, уязвим ли сервер?

1. Определите работающее ядро. Выполните uname -r. Исправление действует только после того, как машина перезагрузится в новое ядро. AlmaLinux советует перезагрузиться и проверить версию с помощью uname -r ^[10].
2. Сверьтесь с трекером поставщика. Найдите CVE-2026-98432 на странице безопасности своего дистрибутива. Red Hat ^[7], Ubuntu ^[8], Debian ^[9] и AlmaLinux ^[10] указывают версии пакетов, содержащие исправление.
3. Проверьте MPTCP. sysctl net.mptcp.enabled показывает, включён ли MPTCP. sudo ss -lnMp выводит прослушивающие сокеты MPTCP и процессы, которым они принадлежат ^[10]. Akamai также рекомендует проверить net.ipv4.tcp_migrate_req ^[11].
4. Найдите сервисы на Go. Программы, собранные с Go 1.24 и новее, в Linux по умолчанию открывают прослушивающие сокеты MPTCP ^[5]. Поэтому любой ваш сервис на Go может открывать путь, который использовала Anthropic.
5. Проверьте производные продукты. Red Hat предупреждает, что любой продукт на основе ядра RHEL, включая OpenShift, OpenStack и Red Hat Virtualization, также может быть затронут ^[6].

Как исправить CVE-2026-98432 или снизить риск?

Настоящее исправление — ядро с патчем. Red Hat называет установку обновлений ядра единственным полным решением ^[6], а команда безопасности Go — лучшим вариантом переход на исправленное ядро ^[5]. Установите обновление ядра от своего дистрибутива, перезагрузитесь и проверьте работающую версию.

Что делать до выхода патча?

• Отбрасывайте TCP-пакеты с опциями IPv4. Red Hat публикует, а трекер Ubuntu приводит как обходное решение от пользователей, правило nftables, которое отбрасывает входящие IPv4 TCP-пакеты с IP-заголовком длиннее базовых 20 байт, то есть пакеты с опциями (ip hdrlength > 5) ^[6][8]. Обычные опции TCP, например временные метки и масштабирование окна, находятся в TCP-заголовке и правилом не затрагиваются ^[8]. Оба поставщика отмечают, что правило снижает риск, но не может полностью предотвратить эксплуатацию ^[6][8].
• Учитывайте ограничения правила. AlmaLinux отмечает, что её вариант правила не сохраняется после перезагрузки, трафик между контейнерами на одном хосте может его обходить, на маршрутизирующих хостах оно отбрасывает и пересылаемые пакеты, а также нарушает работу сетей, использующих метки CIPSO/NetLabel ^[10]. Ubuntu указывает, что для контейнеров с отдельным сетевым стеком правило нужно применять отдельно ^[8].
• Отключите MPTCP, если он не нужен. Параметр net.mptcp.enabled=0 отключает MPTCP во всей системе ^[10]. Akamai также рекомендует установить net.ipv4.tcp_migrate_req=0 ^[11]. Akamai предупреждает, что одно лишь отключение MPTCP не предотвращает эксплуатацию, а только снижает вероятность возникновения гонки ^[11]. Программы на Go также можно отключить от MPTCP с помощью GODEBUG=multipathtcp=0, но команда Go называет такие отключения для отдельных программ ненадёжными ^[5].
• Фильтруйте на границе сети. Для OpenShift Red Hat отмечает, что правила на узле не фильтруют трафик между подами, тогда как фильтрация на сетевой границе перед кластером лишена этого ограничения ^[6].

Помогает ли init_on_free=1?

В одном из сообщений в рассылке oss-security в качестве дополнительной временной меры предлагался параметр загрузки init_on_free=1. Сотрудник команды ядра в CIQ ответил, что он не даёт существенной защиты от этой CVE и не должен иметь веса в бюллетенях ^[12]. Рассматривайте его как общее усиление защиты, а не как меру против этой ошибки.

Эксплуатируется ли CVE-2026-98432?

По состоянию на 3 ноября 2026 года CVE-2026-98432 отсутствует в каталоге известных эксплуатируемых уязвимостей CISA — списке правительства США, куда вносятся уязвимости с подтверждённой эксплуатацией на практике ^[14]. 2 ноября 2026 года Akamai сообщила, что ей неизвестно о публичном работающем эксплойте ^[11]. Это не доказывает, что ошибку никто не эксплуатирует. Существование надёжного эксплойта продемонстрировано ^[4], а технические детали открыто доступны в исправлении ядра ^[3].

Оценка серьёзности со временем также менялась. Впервые CVE была опубликована 15 октября 2026 года ^[1]. Широкое внимание к ней привлёк обзор Anthropic от 27 октября ^[4][11]. С 29 октября по 2 ноября вышли бюллетени поставщиков с временными мерами защиты ^[5][6][10]. Администраторы, бегло просмотревшие исходную запись, могли пропустить более поздние рекомендации.

Что будет дальше?

Red Hat называет своё расследование продолжающимся и обещает обновлять бюллетень по мере появления новой информации ^[6]. Следует ожидать, что оставшиеся пакеты, например ядро реального времени RHEL 9 и образы OpenShift ^[7], а также ядра Ubuntu, исправления для которых ещё в работе ^[8], получат исправления в ближайшие дни или недели. Сверяйтесь с трекерами поставщиков, а не с новостными сводками: в первые недели эти страницы менялись несколько раз.

Исправление ядра оставляет открытой одну связанную проблему. В описании ядра сказано, что функция tcp_v6_reqsk_destructor() в IPv6 имеет ту же проблему с миграцией для опций, устанавливаемых только через CALIPSO, и что она будет решена отдельным патчем ^[2]. Политика скоординированного раскрытия Anthropic отводит 90 дней на выпуск исправлений и ещё 45 дней до обсуждения подробностей сверх публичного бюллетеня ^[4]. Поэтому дополнительные технические детали могут появиться позже.

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