Критическая уязвимость Linux TCP с оценкой 9,8 из 10 по CVSS получила исправления для Red Hat Enterprise Linux 8, 9 и 10. CVE-2026-98432 позволяет удалённому неаутентифицированному атакующему добраться до ошибки управления памятью через любой открытый IPv4 TCP-порт; для администраторов это означает, что обычный плановый патч ядра лучше превратить в приоритетную задачу.
Проблема существует в ядре Linux с ветки 4.4, а upstream-исправление появилось в октябре. По данным The Hacker News, изначально Red Hat оценивала риск как Moderate с CVSS 5,9, но затем повысила оценку до Critical — 9,8. Причина понятна: дефект потенциально ведёт не только к отказу в обслуживании, но и к удалённому выполнению кода с отсутствием логина, учётной записи или действий со стороны пользователя.
Ошибка находится в обработке IPv4 TCP-соединений. Когда сервер принимает новое подключение, ядро передаёт IP-опции из входящего запроса новому сокету без отдельного копирования. Если клиент повторно отправит запрос на соединение в момент, когда другой процессор ещё читает эти данные, возникает race condition: ядро может обратиться к уже освобождённой памяти. Для запуска гонки используются TCP-пакеты с IPv4-опциями Record Route или Timestamp. Основной IPv6-путь, по имеющейся информации, не затронут.
Red Hat выпустила обновления 1 ноября: для RHEL 8.10 нужен kernel 4.18.0-553.182.1.el8_10, для RHEL 9.8 — 5.14.0-687.64.1.el9_8, для RHEL 10.2 — 6.12.0-211.72.1.el10_2. После установки потребуется перезагрузка. Проверить фактически загруженную версию можно через uname -r; наличие пакета в репозитории само по себе не означает, что сервер уже защищён.
У Ubuntu ситуация менее удобная для тех, кто ждёт обновления в штатном канале. Патчи для Ubuntu 22.04 LTS, 24.04 LTS и 26.04 LTS на 2 ноября находились в ветке -proposed, которая не подключается автоматически. Там доступны ядра 5.15.0-203.213, 6.8.0-149.149 и 7.0.0-43.43 соответственно. Canonical тестирует ядра более чем на 2 000 сертифицированных серверах и устройствах перед широким выпуском, но дату переноса исправлений в обычные обновления не назвала. Для Ubuntu 20.04, 18.04 и 16.04 готового исправления ещё нет; старые поддерживаемые релизы требуют Ubuntu Pro и Expanded Security Maintenance.
Другие поставщики отреагировали быстрее или уже завершили работу: Debian, Oracle Linux и SUSE выпустили исправления в октябре, Amazon Linux закрыла проблему в пакетах с 24 по 30 октября. При этом Amazon оценила CVE-2026-98432 в 8,1 и классифицировала её как Important, указывая на наиболее вероятный сценарий падения системы с возможным повреждением памяти. Разница в оценках — не повод выбирать удобную цифру: она отражает предположения вендора о конфигурациях и сложности эксплуатации, а не отменяет сам дефект в сетевом стеке.
Временная защита тоже имеет неприятные оговорки. Red Hat предложила правило nftables, отбрасывающее входящие IPv4 TCP-пакеты с IP-опциями. Оно блокирует известный способ запуска гонки, но не считается полной защитой и может сломать легитимные нагрузки, использующие такие опции. Кроме того, фильтр действует на конкретном хосте: трафик между контейнерами на одной машине может его обойти. Отключение Multipath TCP, которое встречалось в рекомендациях, Canonical не считает достаточной мерой: уязвимый код расположен в IPv4 TCP, а не в MPTCP.
Подтверждённых атак в реальной среде пока нет: CVE отсутствовала в каталоге CISA Known Exploited Vulnerabilities по состоянию на выпуск от 30 октября. Но игнорировать её из-за этого рискованно. Anthropic сообщила, что внутренней исследовательской модели удалось собрать рабочий удалённый root-эксплойт для Linux-сервера с MPTCP listener: утечка адреса ядра заняла 48 минут, получение root shell — ещё пять. Код эксплойта не публиковался, зато в открытом доступе уже есть демонстрационный код, который провоцирует гонку и проверяет утечку освобождённой памяти в SYN-ACK.
Для команд эксплуатации приоритет прост: инвентаризировать интернет-доступные Linux-хосты, сопоставить версию загруженного ядра с исправленными пакетами, обновить и перезагрузить системы в ближайшее окно. В средах, где обновление временно невозможно, nftables-правило может снизить риск после проверки совместимости, но не заменить патч. История с этой уязвимостью Linux TCP хорошо показывает, почему «ядро обновим на следующем квартале» перестаёт быть нейтральным решением: сетевой баг, доступный без учётных данных, быстро становится предметом не только исследований. Дополнительные технические детали и сведения о демонстрационном коде собраны в материале .
