Назад

2026/11/04

CVE-2026-98432: use-after-free в TCP ядра Linux, удалённый root с помощью ИИ через MPTCP и защита корпоративного Linux

Гонка в обработке IPv4 TCP в Linux, продемонстрированный удалённый root через MPTCP, исправления и меры для RHEL, Ubuntu, Oracle Linux и Debian.

Информация проверена: 3 ноября 2026 г. | Технический анализ LOGIQ

В октябре 2026 года была раскрыта уязвимость типа use-after-free (UAF), CVE-2026-98432, в обработке IPv4 TCP-соединений ядра Linux. Команда CVE ядра Linux опубликовала уведомление 15 октября. 27 октября Anthropic сообщила, что её невыпущенная внутренняя исследовательская модель продемонстрировала неаутентифицированное удалённое выполнение команд с правами root на сервере Linux с прослушивающим сокетом MPTCP (Multipath TCP). Важно не смешивать конкретные условия этого эксплойта с более широкими рисками уязвимости и отказа в обслуживании, которые касаются обычных IPv4 TCP-сервисов.

Ключевые выводы

  • Уязвимость — это состояние гонки в обычной обработке запросов на IPv4 TCP-соединение, присутствующее начиная с Linux 4.4. Для самой ошибки MPTCP не требуется.
  • Демонстрация удалённого получения root от Anthropic была направлена на сервер с прослушивающим сокетом MPTCP; другим TCP-сервисам по-прежнему грозят сбои, отказ в обслуживании и повреждение памяти.
  • Red Hat оценивает проблему как Critical (CVSS v3.1 9.8) и 1 ноября выпустила исправленные ядра для RHEL 8, 9 и 10. На 3 ноября исправления для Ubuntu всё ещё находились в работе.
  • Установите одобренное поставщиком исправленное ядро, перезагрузитесь и проверьте работающее ядро. Временные меры снижают риск, но не заменяют исправление.

Где возникает гонка

Проблема связана с трёхэтапным рукопожатием IPv4 TCP. Параметры IP, хранящиеся в сокете запроса (ireq->ireq_opt), могут передаваться в inet_opt дочернего сокета в ходе tcp_v4_syn_recv_sock() без копирования. Если другой CPU обрабатывает повторно переданный SYN и формирует SYN/ACK в момент уничтожения дочернего сокета, память параметров может быть освобождена, пока она ещё используется. Последующее обращение к ней из таких функций, как ip_options_build(), может вызвать UAF.

Связанная гонка существует при миграции сокетов запроса через net.ipv4.tcp_migrate_req=1 или BPF_SK_REUSEPORT_SELECT_OR_MIGRATE, когда данные параметров могут совместно использоваться исходным и клонированным сокетами запроса. Уязвимое поведение восходит к Linux 4.4, но реальную подверженность нужно оценивать для каждого ядра поставщика отдельно, с учётом бэкпортов.

Исправляющий коммит в основной ветке e3f33b0a1d89 (“ipv4: free inet_opt and ireq_opt after an RCU grace period”) заменяет немедленное освобождение памяти в inet_sock_destruct() и tcp_v4_reqsk_destructor() на отложенное через RCU освобождение с помощью kfree_rcu(). В уведомлении Linux CVE указаны исправления в версиях ядра 6.12.113, 6.18.56, 7.2.10 и 7.3-rc7. Исходный путь IPv6 не является той же уязвимостью, хотя путь миграции IPv6 с участием CALIPSO устраняется отдельным патчем.

Не путайте продемонстрированный удалённый root-доступ с общей подверженностью

Доказательство концепции от Anthropic было направлено на сервер с прослушивающим сокетом MPTCP и сочетало утечку информации об адресах ядра с перехватом потока управления. По отчёту, в эксперименте на получение утечки информации ушло около 48 минут, а на выполнение команд — ещё пять минут. Поскольку проигранная гонка лишь срывает рукопожатие, а не приводит к сбою системы, атакующий может повторять попытки. Однако сама UAF находится в обычной обработке запросов на IPv4 TCP-соединение, а не только в коде MPTCP.

Та же техника удалённого получения root не была продемонстрирована для каждого обычного TCP-сервиса без MPTCP. Тем не менее неверно и предполагать, что отключение MPTCP делает систему полностью безопасной. Red Hat указывает, что MPTCP не является обязательным условием, что системы с отключённым MPTCP (по умолчанию) остаются уязвимыми, и предупреждает о неаутентифицированных удалённых сбоях, отказе в обслуживании и повреждении памяти в стандартных IPv4 TCP-сервисах.

Оценки основных поставщиков: серьёзность и статус исправлений

Статус на 3 ноября 2026 г. Страницы поставщиков меняются; перед любыми действиями всегда проверяйте актуальную запись.

ПоставщикСерьёзностьСтатус исправления
Red HatCritical, CVSS v3.1 9.8Исправленные ядра выпущены 1 ноября: RHEL 8 (RHSA-2026:93414; kernel-rt для NFV RHSA-2026:93415), RHEL 9 (RHSA-2026:93412), RHEL 10 (RHSA-2026:93413). RHEL 9 kernel-rt и OpenShift (RHCOS) всё ещё значатся как Affected. RHEL 6 и 7 не затронуты.
UbuntuPriority High; CVSS 9.8linux для 26.10, 26.04, 24.04 и 22.04: Vulnerable, work in progress. 20.04, 18.04 и 16.04: Vulnerable. Исправленный пакет пока не выпущен.
Oracle LinuxImportant; предварительный CVSS 8.1Исправления UEK от 16 октября (ELSA-2026-500397, -500398, -500399) для OL7–OL10. Исправления RHCK от 2 ноября для OL8 (ELSA-2026-93414) и OL10 (ELSA-2026-93413); для OL9 исправление RHCK пока не указано.
Debian(Security Tracker)Исправлено в bookworm 6.1.190-1 (DLA-4841-1), bookworm linux-6.12 6.12.113-1~deb12u1 (DLA-4850-1) и trixie 6.12.113-1 (DSA-6568-1); в forky и sid исправлено.

Red Hat (оценка пересмотрена 30 октября; бюллетень последний раз обновлён 2 ноября). Официальная страница CVE оценивает проблему как Critical, CVSS v3.1 9.8, поскольку неаутентифицированный удалённый злоумышленник может повредить память ядра или вызвать сбой системы с помощью обычного трафика IPv4 TCP. RHEL 8, 9, 10 и OpenShift указаны как затронутые; ядро RHEL 7 указано как незатронутое, поскольку соответствующий код в нём отсутствует. С 1 ноября в данных CVE от Red Hat перечислены исправленные ядра: kernel-4.18.0-553.182.1.el8_10 (RHEL 8), kernel-5.14.0-687.64.1.el9_8 (RHEL 9) и kernel-6.12.0-211.72.1.el10_2 (RHEL 10). Бюллетень безопасности RHSB-2026-016 всё ещё имел статус «продолжается» и является источником процедуры временного устранения. Не выдавайте более старые оценки из вторичных источников, например 5.9 или 8.1, за текущую оценку Red Hat.

Ubuntu (официальная таблица последний раз обновлена 30 октября). CVSS для CVE — 9.8, а собственный приоритет Ubuntu — High. Стандартные пакеты linux для Ubuntu 26.10, 26.04, 24.04 и 22.04 помечены как “Vulnerable, work in progress”, а запланированные версии исправлений указаны на странице; 20.04, среди прочих статусов, помечен как Vulnerable. Варианты ядра AWS, Azure, HWE, RT и другие необходимо оценивать по отдельности. “Work in progress” не означает, что исправление выпущено.

Oracle Linux. Собственная оценка Oracle — Important, с предварительным баллом CVSS 8.1. Исправления UEK для OL7, OL8, OL9 и OL10 датированы 16 октября, а исправления RHCK для OL8 и OL10 последовали 2 ноября. Исправления в UEK нельзя распространять на RHCK или на каждый минорный выпуск; оценивайте установленное ядро и конкретные исправления.

Debian. Официальный Security Tracker отмечает как исправленные, в частности, bookworm-security 6.1.190-1 и trixie-security 6.12.113-1. Проверяйте как версии установленных пакетов, так и работающее ядро после перезагрузки.

Результаты CVSS у CNA и у поставщиков могут различаться из-за особенностей конфигураций и исправлений в разных дистрибутивах, а оценки могут меняться. Всегда фиксируйте дату проверки и ссылку на каждый официальный источник.

Защитные меры: временное устранение не заменяет патч

Первоочередная задача — установить одобренное поставщиком исправленное ядро и после перезагрузки проверить работающую версию. Если исправление ещё недоступно, рассмотрите закрытие ненужных публичных TCP-сервисов, ограничение разрешённых сетей-источников и приоритетный мониторинг открытых наружу хостов.

В бюллетене Red Hat описана мера на основе nftables, которая отбрасывает входящие пакеты IPv4 TCP, содержащие параметры IP в заголовке IPv4:

table inet cve_2026_98432 {
  chain input {
    type filter hook input priority -310; policy accept;
    ip protocol tcp ip hdrlength > 5 counter drop
  }
}

Это не полная защита: она может нарушить работу нагрузок, использующих параметры IP, и перед внедрением её нужно протестировать на влияние на бизнес-трафик. Обычные параметры TCP в заголовке TCP по-прежнему разрешены; речь не идёт о блокировке поля TCP Options. В OpenShift правила на уровне узла не фильтруют трафик между подами внутри сети кластера, поэтому там важна фильтрация на границе сети. Удалите таблицу, как только будет запущено исправленное ядро.

Совет: после установки исправления сравните вывод uname -r с исправленной версией в бюллетене вашего поставщика и сохраните этот вывод вместе с записью об изменении. Установленный, но ещё не загруженный пакет не закрывает уязвимость.

В Linux пакет net языка Go начиная с Go 1.24 по умолчанию включает MPTCP для прослушивающих сокетов. Команда Go документирует GODEBUG=multipathtcp=0 как способ его отключения (также доступен в виде строки godebug в go.mod). Предложение изменить значение по умолчанию всё ещё обсуждается, и сопровождающие Go указывают, что настоящим исправлением является пропатченное ядро. Эта настройка может снизить подверженность зависящему от MPTCP пути атаки, продемонстрированному Anthropic, но не устраняет саму UAF в ядре. Проверьте использование MPTCP для каждого сервиса отдельно.

Взгляд LOGIQ

При сопровождении корпоративного Linux нельзя судить о безопасности только по публичному баллу CVSS или выводу uname -r. Оценивайте в совокупности выпуск ОС, семейство ядра (например, UEK или RHCK), выпуск пакета, текущее загруженное ядро, сетевую доступность, настройки MPTCP, исправления поставщика и подтверждение перезагрузки. Отслеживайте всю цепочку — от оценки влияния и проверки до развёртывания и операционного мониторинга.

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

Первичные источники и ссылки