ИИтог

В ядре Linux найдена уязвимость CVE-2026-98432: CVSS 9,8 и 5,9

безопасностьРедакция ИИтогHacker News🔥61Рейтинг ИИтог61Влияние55Новизна60Релевантность75Неожиданность55Участники35Достоверность80
В ядре Linux найдена уязвимость CVE-2026-98432: CVSS 9,8 и 5,9

CVE-2026-98432, ошибка use-after-free (обращение к освобождённой памяти) в пути TCP-рукопожатия IPv4 в ядре Linux. Два процессора работают со связанными запросным и дочерним сокетами, и оба могут ссылаться на один и тот же объект с IP-опциями. Один путь освобождает объект сразу, а другой, защищённый только как читатель RCU, продолжает им пользоваться. В итоге в коде, достижимом по сети, остаётся «висячий» указатель ядра.

Автор разбора на penligent.ai разводит три разных утверждения. В записи CVE стоит оценка CVSS 3.1, 9.8: это худший случай (достижимо по сети, без аутентификации, высокое влияние на конфиденциальность, целостность и доступность). Анализ продукта у Red Hat даёт более низкую оценку 5.9, потому что считает эксплуатацию трудной гонкой и более осторожно оценивает последствия в поддерживаемых продуктах. Отдельно команда Frontier Red Team компании Anthropic сообщила о рабочей цепочке удалённого выполнения кода с правами root против Linux-сервера со слушателем Multipath TCP (MPTCP) в контролируемой лаборатории. Это серьёзное свидетельство эксплуатируемости при конкретной конфигурации, но не доказательство, что так можно скомпрометировать любой непропатченный сервер, любой обычный TCP-слушатель или любую сборку дистрибутива. По мысли автора, эти три утверждения дополняют друг друга и ни одно не стоит ни отбрасывать, ни растягивать за пределы его области.

Техническая суть. При серверной части рукопожатия TCP ядро создаёт лёгкий запросный сокет. Когда рукопожатие проходит, tcp_v4_syn_recv_sock() передаёт указатель ireq_opt запроса новому дочернему сокету как inet_opt, не копируя объект. Тем временем другой процессор может обработать повторно отправленный SYN по тому же запросу и отправить ещё один SYN-ACK через tcp_check_req(). Функции вроде tcp_v4_send_synack() и inet_csk_route_req() читают IP-опции запроса внутри критической секции чтения RCU, а ip_build_and_send_pkt() и ip_options_build() затем разыменовывают поля объекта. Но деструктор освобождает объект обычным kfree(), который не дожидается завершения уже начатых RCU-чтений. Если дочерний сокет уничтожен, пока путь повторного SYN ещё читает опции, второй процессор читает память, которая уже не принадлежит объекту. Чем это обернётся, зависит от того, что займёт освобождённое место: от безобидного чтения старых байтов и сбоя до утечки данных и, при достаточном контроле над размещением и временем, более мощных примитивов чтения, записи или управления потоком выполнения.

Есть и родственный случай, миграция запросов. Если включён net.ipv4.tcp_migrate_req=1 либо миграцией управляет программа BPF_SK_REUSEPORT_SELECT_OR_MIGRATE, ядро может клонировать запросный сокет, и старый запрос с клоном временно делят один объект опций. Процессор, державший ссылку на старый запрос, может продолжать им пользоваться, пока клон освобождается.

Исправление. Патч влит в апстрим коммитом e3f33b0a1d89 под названием «ipv4: free inet_opt and ireq_opt after an RCU grace period». Основное исправление заменяет немедленное освобождение на kfree_rcu() в соответствующих деструкторах, откладывая возврат памяти до окончания периода ожидания RCU (grace period). Для случая миграции изменены и inet_sock_destruct(), и tcp_v4_reqsk_destructor(). Глобальную блокировку не вводили: она ударила бы по масштабируемости горячего сетевого пути, поэтому освобождение просто согласовали с моделью синхронизации, которой уже пользуются читатели.

Про IPv6: утверждение «IPv6 не затронут» слишком широкое. Основная ошибка передачи владения не касается обычного создания дочернего сокета IPv6, потому что там опции дублируются, а не передаются тем же указателем. Но апстрим-текст упоминает отдельный случай миграции запросов с ipv6_opt при наличии CALIPSO, который обрабатывается отдельно.

Что не установлено. Ни один из процитированных авторитетных источников не подтверждает массовой эксплуатации в публичном интернете. Anthropic показала удалённое выполнение команд с правами root против контролируемой цели с MPTCP-слушателем, это сильнее, чем доказательство только вызова сбоя, и должно влиять на срочность. Но измеренной распространённости уязвимых MPTCP-сервисов, универсальной доли успеха и доказательства, что цепочка работает без изменений на разных сборках ядра, архитектурах CPU, аллокаторах, профилях усиления защиты и сетевых путях, нет. Большой поток повторных SYN сам по себе не признак эксплуатации: такие повторы возникают из-за потерь пакетов, асимметричной маршрутизации, перегруженных сервисов и промежуточных устройств. Сетевой алерт помогает расставить приоритеты для расследования, но не доказывает use-after-free внутри ядра.

Проверка версий. Единой строки версии апстрима, которая точно помечает каждое вендорское ядро, не существует: корпоративные дистрибутивы переносят исправления, сохраняя «старую на вид» базовую версию, а облачные провайдеры и вендоры устройств собирают собственные ядра. Сканер, сравнивающий только uname -r со списком апстрим-релизов, даёт и ложные срабатывания, и пропуски. Надёжный вывод даёт бюллетень вендора, журнал изменений пакета, метаданные сборки, заявление VEX или прямое подтверждение переноса коммита. Debian security tracker воспроизводит апстрим-описание и сопоставляет проблему с исправленными пакетами ядра Debian, а страница Ubuntu CVE указывает те же коммиты внедрения и исправления и отдельно отслеживает множество вариантов ядер Ubuntu.

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

Ключевые факты

  • CVE-2026-98432, use-after-free в пути TCP-рукопожатия IPv4 в ядре Linux: IP-опции освобождаются обычным kfree(), пока другой процессор ещё читает их как RCU-читатель.
  • Оценки расходятся: в записи CVE, CVSS 3.1 равный 9.8 (худший случай), у Red Hat, 5.9 (эксплуатация считается трудной гонкой).
  • Команда Frontier Red Team компании Anthropic сообщила о рабочей цепочке удалённого выполнения кода с правами root против сервера со слушателем MPTCP в лаборатории; это не доказывает уязвимость любого сервера.
  • Апстрим-исправление, коммит e3f33b0a1d89: освобождение через kfree_rcu() после grace period; для миграции запросов (tcp_migrate_req=1 или BPF-программа) изменены также inet_sock_destruct() и tcp_v4_reqsk_destructor().
  • Рекомендация: поставить исправленное ядро от вендора, перезагрузиться и сохранить подтверждение; сравнения uname -r с апстрим-списком недостаточно, а отключение MPTCP патч не заменяет.

Почему это важно

Ошибка лежит в сетевом пути ядра Linux, достижимом по TCP-трафику, а оценки серьёзности сильно расходятся: 9.8 в записи CVE против 5.9 у Red Hat. Кроме того, Anthropic Frontier Red Team показала в лаборатории удалённое выполнение кода с правами root, что сильнее, чем доказательство одного лишь сбоя. Разбор полезен тем, что объясняет, как читать три разных утверждения (апстрим-запись, оценку вендора, исследовательский эксплойт), не смешивая их.

Кому это важно

Администраторам и командам безопасности, у которых есть серверы на Linux. Особенно тем, кто выставляет наружу слушатели MPTCP: именно эту среду проверяло публичное исследование. Быстрой инвентаризации, по словам автора, заслуживают и интернет-шлюзы, балансировщики нагрузки, узлы Kubernetes, VPN-точки входа, обратные прокси и устройства на Linux, даже если MPTCP на них намеренно не включали. Также важно владельцам дистрибутивов и сборок ядра, которым нужно сопоставить статус с коммитом e3f33b0a1d89.

Как это применить

Порядок из разбора: определить достижимые Linux TCP-сервисы, выяснить, какое вендорское ядро реально запущено, установить исправленную сборку от вендора, перезагрузиться в неё и сохранить подтверждение, что запущенное ядро содержит исправление. Статус брать из бюллетеня вендора, журнала изменений пакета, метаданных сборки, заявления VEX или подтверждения переноса исправления, а не из сравнения uname -r с апстрим-списком. Для Debian и Ubuntu есть страницы трекеров, сопоставляющие проблему с исправленными пакетами. Если MPTCP не нужен, его отключение может снизить непосредственную угрозу, но заменой патча не является.

Можно ли доверять

Материал, сторонний разбор на сайте penligent.ai; имя автора в тексте не названо. Технические детали (пути в ядре, название коммита e3f33b0a1d89, оценки CVSS) подаются со ссылкой на апстрим-описание и страницы Debian и Ubuntu, а вывод об ограниченности результата Anthropic принадлежит автору разбора. Как именно устроена цепочка эксплуатации Anthropic и насколько она надёжна, в тексте не сказано; дат раскрытия и публикации, а также номеров исправленных версий ядра в нём нет. Доказательств массовой эксплуатации автор не приводит и прямо пишет, что их нет у процитированных источников.

Риски и подводные камни

Сканеры, сравнивающие только uname -r с апстрим-версиями, дают ложные срабатывания и пропуски, потому что дистрибутивы переносят исправления в «старые на вид» версии ядра. Нельзя считать любой всплеск повторных SYN признаком атаки: такие повторы бывают из-за потерь пакетов, асимметричной маршрутизации, перегрузки и промежуточных устройств. Отключение MPTCP не убирает саму ошибку в IPv4. Формулировка «IPv6 не затронут» слишком широка: основная ошибка к обычному IPv6-пути не относится, но отдельный случай миграции запросов с ipv6_opt при CALIPSO обрабатывается отдельно. Наконец, результат Anthropic относится к конкретной конфигурации и не показывает универсального успеха эксплойта.