В TCP-коде ядра Linux нашли уязвимость CVE-2026-98432: это гонка (race condition) при установке новых IPv4-соединений, из-за которой ядро читает уже освобождённую память. Команда CVE ядра поставила 9.8 из 10 по шкале CVSS. Проблема затрагивает Ubuntu, Red Hat Enterprise Linux (RHEL) и другие дистрибутивы; исправленные ядра на 29 октября есть у Debian, Oracle Linux, SUSE и Amazon Linux, а у Ubuntu и RHEL — нет.
Что именно ломается в TCP-стеке
Гонка возникает во время TCP handshake. Когда соединение завершается, ядро передаёт новому сокету IP-опции, сохранённые с ожидающим запросом, без копирования. Если сокет уничтожается, пока другой CPU ещё использует эти опции для ответа на повторно присланный запрос соединения, ядро читает освобождённую память — классический use-after-free.
IPv6 эта гонка не затрагивает: для IPv6-соединений ядро копирует опции. Баг появился в Linux 4.4. Разработчики ядра применили исправление 5 октября — за десять дней до публикации CVE. Исправление заставляет ядро дождаться, пока другие CPU закончат читать опции, и только потом освобождать память.
Кто уязвим, а кто уже закрылся
Статус на 29 октября (по данным вендорских advisories):
| Дистрибутив | Оценка вендора | Статус | Пакет или advisory |
|---|---|---|---|
| Ubuntu 22.04/24.04/26.04/26.10 LTS | Priority High | В работе | Нет |
| Ubuntu 16.04, 18.04, 20.04 | Priority High | Уязвим | Нет |
| RHEL 8, 9, 10, OpenShift 4 | Moderate 5.9 (CVE page), Important 8.1 (advisory) | Исправление отложено | Нет |
| RHEL 7 | Not applicable | Не затронут | Не нужен |
| Amazon Linux 2023, kernel6.18 | Important 7.0 | Исправлено 24 октября | kernel6.18-6.18.56-125.164.amzn2023 (ALAS2023-2026-3251) |
| Amazon Linux 2023, kernel6.12 | Important 7.0 | Исправлено 29 октября | kernel6.12-6.12.113-138.209.amzn2023 (ALAS2023-2026-3335) |
| Amazon Linux 2, Amazon Linux 2023 (kernel) | Important 7.0 | Ожидает исправления | Нет |
| Oracle Linux 7, 8, 9, 10, UEK | Important 8.1 | Исправлено 16 октября | ELSA-2026-500397, ELSA-2026-500398, ELSA-2026-500399 |
| Debian trixie (stable) | Оценки нет | Исправлено 16 октября | linux 6.12.113-1 (DSA-6568-1) |
| Debian 12 (bookworm) | Оценки нет | Исправлено 17 и 22 октября | linux 6.1.190-1 (DLA-4841-1), linux-6.12 6.12.113-1~deb12u1 (DLA-4850-1) |
| SUSE Linux Micro 6.2, openSUSE Leap 16.0 | Important 8.1 | Исправлено | kernel-default 6.12.0-160000.40.1 или новее |
| SLES 15 SP4–SP6 LTSS, SLES 16.0, SLE Micro 5.3–5.5 | Important 8.1 | Тестируется | Нет |
| SLES 15 SP7 | Important 8.1 | Затронут, исправление в работе | Нет |
Ubuntu также относит к уязвимым или «в работе» свои cloud-, FIPS- и real-time-ядра. Red Hat пишет, что исправления «в настоящее время отложены до будущего обновления». Ни Red Hat, ни Ubuntu не называют дату выпуска.
Почему оценки расходятся: 5.9 против 9.8
Команда CVE ядра добавила оценку 9.8 в запись CVE 24 октября — через девять дней после публикации. Её расчёт предполагает атакующего, который отправляет TCP-запрос с опциями IPv4 Record Route или Timestamp, а затем повторяет запрос, пытаясь выиграть гонку. Сложность атаки команда оценила как низкую: обе стороны гонки «индуцированы атакующим». В таком случае баг может отправить атакующему соседнюю память ядра, повредить её или обрушить систему.
Red Hat на своей странице CVE ставит Moderate и 5.9, потому что гонку трудно выиграть: наиболее вероятный исход — крах ядра, повреждение памяти возможно лишь теоретически, и «не продемонстрировано влияния на конфиденциальность или целостность». При этом машиночитаемый advisory-файл Red Hat, обновлённый 29 октября, указывает Important и 8.1 с высоким влиянием на конфиденциальность и целостность. В тот же день баг-трекер Red Hat сменил важность с medium на high, а страница CVE всё ещё показывала Moderate и 5.9. Oracle и SUSE тоже ставят 8.1 с тем же CVSS-вектором, что и advisory Red Hat: их оценки совпадают с оценкой команды ядра по всем метрикам, кроме сложности атаки — вендоры считают её высокой, команда ядра низкой. Amazon ставит 7.0.
На 28 октября Национальная база уязвимостей (NVD) своей оценки не добавила и показывала 9.8 от команды ядра. Страница Ubuntu тоже показывает 9.8.
Что собрала Anthropic
Anthropic 27 октября сообщила, что её ИИ-модель Claude написала эксплойт, использующий эту уязвимость: удалённый атакующий без учётных данных выполняет команды от имени root на Linux-серверах с multipath TCP listener. Эксплойт написан после «первоначального промпта», уточняет компания.
Эксплуатация идёт в два этапа. Сначала гонка заставляет ядро вернуть атакующему лишние байты. Как только в одном из ответов появляется адрес ядра, атакующий обходит KASLR — рандомизацию адресов памяти ядра. Затем тот же баг переполняет буфер и перезаписывает указатель обратного вызова адресом полезной нагрузки, которую атакующий заранее разместил в памяти ядра. Когда ядро вызывает этот указатель, полезная нагрузка выполняет выбранную атакующим shell-команду от root.
Проигранная гонка лишь обрывает одну попытку соединения и не роняет систему, поэтому атакующий может пробовать снова. В тесте Anthropic утечка адреса ядра заняла 48 минут, а до выполнения команды прошло ещё 5 минут. Кода эксплойта, версии ядра и конфигурации, на которой проводился тест, в посте нет.
MPTCP: связь, которой нет в CVE
Ни запись CVE, ни исправление не упоминают multipath TCP (MPTCP). Связь между этой функцией и багом появляется только из поста Anthropic. MPTCP позволяет одному соединению использовать несколько сетевых путей одновременно; в Linux приложение должно само запросить MPTCP при открытии сокета. Red Hat говорит, что гонку может вызвать удалённый атакующий, дотянувшийся до открытого TCP-сервиса, но root-эксплойт Anthropic нацелен на серверы с multipath TCP listener. Может ли сервер без него быть захвачен тем же способом, в посте не сказано.
На 29 октября ни один вендорский advisory, запись CVE или пост Anthropic не сообщают об атаках с использованием уязвимости. В копии каталога Known Exploited Vulnerabilities CISA, которую CIRCL из Люксембурга обновил 28 октября, её нет.
Что делать администратору
Если ваш дистрибутив выпустил исправленное ядро — ставьте его. Пакеты и advisory для Debian, Oracle Linux, SUSE и Amazon Linux перечислены в таблице выше. Это ровно те же эксплуатационные шаги, что и при закрытии других дыр ядра: 14-летняя уязвимость ядра Linux и четыре уязвимости повышения привилегий до root закрывались обновлением пакета linux из репозитория дистрибутива.
Если вы собираете ядро сами, исправление есть в Linux 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 и 7.3. Команда CVE ядра рекомендует обновляться до последнего стабильного ядра: сообщество не поддерживает выборочный перенос отдельных исправлений (cherry-picking).
У Ubuntu, RHEL и части релизов Amazon Linux и SUSE исправленного ядра пока нет. Red Hat пишет, что ни одна доступная мера смягчения не отвечает её критериям — простота развёртывания, пригодность для большинства установок и стабильность. Другие вендорские advisory мер смягчения не перечисляют. Отключать ли multipath TCP или блокировать входящие запросы соединений с IP-опциями, чтобы снизить риск, ни advisory, ни пост Anthropic не уточняют.
Частые вопросы
Кого касается CVE-2026-98432?
Всех, кто держит Linux-серверы с открытым TCP-сервисом на уязвимых ядрах. В первую очередь — инсталляции Ubuntu и RHEL, где исправленного ядра на 29 октября не было. Серверы с multipath TCP listener — это конфигурация, на которой Anthropic показала root-эксплойт.
Как проверить, уязвимо ли моё ядро?
Сравните версию ядра (uname -r) с исправленными: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 или 7.3. Если вы на дистрибутивном ядре, ориентируйтесь на пакет вендора: у Debian это linux 6.12.113-1 и linux 6.1.190-1, у Amazon Linux — kernel6.18-6.18.56-125.164.amzn2023 и kernel6.12-6.12.113-138.209.amzn2023.
Почему оценка 9.8, если Red Hat ставит 5.9?
Расхождение в сложности атаки: команда CVE ядра считает обе стороны гонки «индуцированными атакующим» и ставит сложность низкую, Red Hat — высокую, потому что гонку трудно выиграть. При этом advisory Red Hat от 29 октября уже указывает 8.1 и Important — на той же странице CVE всё ещё Moderate и 5.9.
Затронут ли IPv6?
Нет. Гонка возникает только при установке IPv4-соединений: для IPv6 ядро копирует IP-опции, поэтому чтения освобождённой памяти не происходит.
Есть ли эксплойт в открытом доступе?
Anthropic описала двухэтапный эксплойт и тайминги (48 минут на утечку адреса ядра, ещё 5 — до выполнения команды), но кода, версии ядра и конфигурации теста в посте нет. Публичного эксплойта в вендорских advisory и записи CVE не упоминается.
Атаки уже фиксировали?
Нет. На 29 октября ни вендорские advisory, ни запись CVE, ни пост Anthropic не сообщают об эксплуатации. В каталоге Known Exploited Vulnerabilities CISA (копия CIRCL от 28 октября) уязвимости нет.
Что делать, если обновиться нельзя?
Red Hat заявляет, что доступной меры смягчения, отвечающей её критериям, нет. Ни один вендорский advisory и пост Anthropic не уточняют, снижает ли риск отключение multipath TCP или блокировка входящих запросов с IP-опциями. Если обновление отложено, остаётся минимизировать поверхность: ограничивать доступ к TCP-сервисам по сети и следить за анонсами вендора.
Что делать тем, кто собирает ядро сам?
Обновиться до последнего стабильного ядра: исправление вошло в 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 и 7.3. Команда CVE ядра не поддерживает перенос отдельных исправлений — только переход на актуальную стабильную ветку.
Как это связано с другими свежими дырами ядра?
Это очередной use-after-free в ядре, который закрывается обновлением пакета linux. Похожая история была с CVE-2025-39964: там баг жил 14 лет и тоже вёл к root и побегу из Docker. CVE-2026-98432 старше — он появился в Linux 4.4, а исправление в upstream применили 5 октября.
Источник: thehackernews.com