TCP use-after-free в Linux: патчить или митигировать?

В вашем ядре есть удалённо достижимый use-after-free в пути TCP-рукопожатия, дистрибутив ещё не выпустил исправление, а кто-то уже показал рабочий эксплойт для получения root. Так что за план: ждать или начать отбрасывать пакеты на файрволе? Уязвимость в TCP ядра Linux, раскрытая как CVE-2026-98432, — отличный пример самого старого решения в security-операциях: патчить или митигировать. И честный ответ такой, что варианты вовсе не равноценны. Только один из них реально устраняет проблему.

Я сам бывал по обе стороны этого решения. Однажды я откладывал экстренное обновление ядра, потому что митигация на бумаге выглядела достаточной. А в другой раз наблюдал, как «временное» правило файрвола восемь месяцев тихо гнило в продакшене, пока все забыли про CVE, которое оно закрывало. Эта уязвимость — хороший повод разобрать, когда какой подход выигрывает, ведь компромиссы здесь на редкость наглядные.

Что на самом деле представляет собой TCP use-after-free

Механика важна, потому что от неё зависит, что митигация может и чего не может. Когда сервер принимает IPv4 TCP-соединение, ядро отслеживает полуоткрытое рукопожатие в легковесном request-сокете, а после его завершения повышает до полноценного сокета. Если в IPv4-заголовке пира были опции, ядро сохраняет их, чтобы вернуть в ответах. Ошибка в том, что ядро передавало эти сохранённые опции новому соединению без копирования, а затем сразу их освобождало, хотя другой CPU мог всё ещё читать их для формирования ответа на рукопожатие. Это и есть use-after-free, достижимый удалённым неаутентифицированным пиром ещё до того, как выполнится хоть одна строка вашего приложения.

Апстрим-исправление от Эрика Дюмазе — четыре строки: два обычных вызова kfree() заменяются на kfree_rcu(), который откладывает освобождение, пока все читатели не закончат работу с памятью. Это канонический фикс для такого класса багов: читатели под RCU держат ссылки, которых вы не видите, поэтому нужно дождаться окончания grace period, прежде чем возвращать память. CNA самого ядра присвоил оценку CVSS 9.8. Red Hat сначала поставил 8.1, а 30 октября поднял до 9.8 Critical, сославшись на отсутствие сетевых предусловий.

Два момента меняют расчёт риска. Во-первых, гонка проигрывается «мягко»: неудачная попытка просто срывает рукопожатие и не кладёт систему в панику, так что атакующий может повторять сколько угодно. Во-вторых, путь эксплуатации, который продемонстрировала Anthropic, нацелен на хосты с листенером multipath TCP. А по данным Go Security Team, программы на Go с версии 1.24 открывают MPTCP-листенеры по умолчанию на Linux, где ядро это позволяет. Проверьте свой парк:

ss -Mlnp                 # MPTCP listeners and their owning processes
sysctl net.mptcp.enabled # 1 means apps may open MPTCP sockets

Пустой вывод ss -M означает, что MPTCP-листенера нет. Но расслабляться рано: команда Go прямо говорит, что базовый баг не привязан к MPTCP. Это общий UAF в обработке рукопожатия, а MPTCP — просто путь, на котором его уже доказали от начала до конца.

Путь патча: исправленное ядро, перезагрузка, готово

Патч скучно описывать, потому что это единственный вариант, который устраняет уязвимость, а не просто меняет её форму. Исправленные ядра вышли в апстриме 11 и 15 октября для всех поддерживаемых стабильных веток. Баг тянется до Linux 4.4, так что под удар попадает много систем «длинного хвоста», включая ядра настолько старые, что апстрим до них уже не доберётся.

Подвох — в перезагрузке. Обновление ядра ничего не даёт, пока машина не загрузится с ним, и вот тут и кроется реальная операционная цена: эвакуированные Kubernetes-ноды, репетиции failover, primary базы данных, который никто не хочет перезапускать в рабочее время. Поэтому совет «просто обновитесь» всегда верен и никогда не достаточен. Нужен план раскатки: сначала канареечные хосты, потом stateless-слои, и только затем stateful-системы в окнах обслуживания. Если вы уже проходили аварийную замену ядра по всему парку, вы знаете, как это бывает. Команды, которые справляются с этим хорошо, репетировали дренаж нод, когда ничего не горело. Привычки защитной инженерии, которые вы вырабатываете в спокойные вторники, окупаются во время уязвимости с CVSS 9.8.

Одна ловушка, о которой стоит сказать: dpkg -l или rpm -q kernel, показывающие исправленный пакет, ничего не значат, если работающее ядро старше. uname -r покажет, что реально выполняется. На RHEL-подобных системах needs-restarting -r прямо скажет, ждёт ли перезагрузка. Я разбирал постинцидентные отчёты, где «пропатченный» парк оказывался парком установленных, но не запущенных ядер. Сверяйте версию, которая работает, с трекером вашего дистрибутива, а не с номером из апстрима: ядра дистрибутивов содержат бэкпорты под собственной нумерацией.

Путь митигации: отбрасываем IPv4-опции, отключаем MPTCP

Опубликованная временная митигация — правило nftables, которое отбрасывает входящие IPv4 TCP-пакеты с IP-опциями, то есть условие срабатывания уязвимого пути. Дополнительно можно отключить MPTCP (sysctl -w net.mptcp.enabled=0), если вы его не используете. Оба действия быстрые, не требуют перезагрузки и разворачиваются через систему управления конфигурацией за пару часов. В этом и привлекательность.

Теперь о том, что должно немного охладить энтузиазм: бюллетень Red Hat прямо говорит, что их правило «снижает подверженность уязвимости, но не может полностью её предотвратить». Перечитайте эту фразу дважды. Митигация сужает поверхность атаки, но не закрывает её. Пакеты с IP-опциями в обычном трафике редки, большинство промежуточных узлов всё равно их отбрасывают, и это одна из причин, почему эксплуатация через открытый интернет считается маловероятной. Но «редко» и «невозможно» — разные слова, а баг сидит в общем коде рукопожатия, а не только в пути с опциями, который кто-то случайно проверил.

Есть и более тонкая цена: митигации создают ложное ощущение закрытия. Тикет переводят в состояние «почти готово», срочность из работы по патчингу уходит, и через шесть недель вы всё ещё работаете на уязвимом ядре за пакетным фильтром, и память о том, почему это вообще делалось, быстро стирается. Я уже писал об этом паттерне в контексте окна для критических CVE в PHP: там команды, которые просто отключили уязвимый компонент, справились лучше тех, кто громоздил умные фильтры. Тот же урок, другой стек.

Патч или митигация: когда что выигрывает

Вот мой честный расклад, сложившийся за годы принятия таких решений под давлением.

• Для вашего дистрибутива есть исправленное ядро. Выигрывает патч, без вариантов. Debian, SUSE Enterprise, Oracle UEK и Amazon Linux уже выпустили исправления. Нет митигации умнее четырёхстрочного фикса из апстрима. Планируйте перезагрузки, раскатывайте кольцами и двигайтесь дальше.
• Исправленного ядра пока нет, а риск реален. Митигируйте немедленно, для этого митигации и существуют. Ubuntu и RHEL в конце октября всё ещё значились как «Vulnerable»/затронутые. Если сервис смотрит в интернет и у вас есть MPTCP-листенер, отбрасывайте пакеты с IP-опциями и отключайте MPTCP сегодня, а исправленное ядро отслеживайте как релиз, без которого вы заблокированы.
• Сервис в интернете, но за управляемым фронтом. Срочность снижается. Рекомендация AWS о том, что трафик, проходящий через их балансировщики, CloudFront или API Gateway, не доходит до инстансов как сырой недоверенный TCP, звучит разумно. Митигируйте всё равно (это дёшево), а патч ставьте в обычном цикле, а не в экстренном.
• Одноядерные системы или системы с одной очередью. Приоритет ниже. Гонке нужна параллельная обработка пакетов на нескольких CPU. Встраиваемые системы и крошечные ВМ получают передышку, но это обычно те машины, которые никто никогда не перезагружает, так что пусть «низкий приоритет» не превращается в «никогда».
• Ядра вне поддержки (апстрим старше 5.10). Митигация — единственный вариант, не зависящий от апстрима. Это сценарий, где митигации действительно выигрывают, потому что альтернатива — бэкпорт вендора, который может так и не появиться. Это также громкий сигнал, что уязвимость — в самой машине, и настоящее решение — её замена.

Главная история — разрыв в дистрибутивах

Должна тревожить не сама уязвимость. Четырёхстрочные фиксы use-after-free каждый месяц попадают в стабильные ядра. Тревожит то, что два крупнейших серверных дистрибутива на планете, Ubuntu и RHEL, спустя больше двух недель после апстрима всё ещё не выпустили исправлений, тогда как Amazon Linux пропатчил все свои ядра, а AlmaLinux, пересборка от сообщества, выложил исправленные ядра в тестирование раньше апстрима. Сообщество на HN это заметило и имеет полное право злиться: это именно те дистрибутивы, которые громче всех рекламируют готовность к серверным нагрузкам.

Для практиков вывод прозаичный: ваше окно уязвимости определяет конвейер бэкпортов вашего вендора, а не апстрим. Из этого следуют две вещи. Во-первых, знайте ссылки на трекеры своих дистрибутивов и действительно за ними следите. Этот CVE в NVD долго висел в статусе «Received» без анализа, в то время как CNA ядра, Red Hat и дистрибутивы уже опубликовали подробные страницы. Во-вторых, считайте скорость реакции дистрибутива критерием выбора. Amazon Linux только что показал заметно более быстрый конвейер исправлений ядра, чем два лидера рынка. В маркетинговой презентации это не важно, но в выходные Хэллоуина, когда появляется CVSS 9.8, — очень важно.

Эксплойт, написанный ИИ, меняет таймер

Самая важная строка в раскрытии легко пролистывается: Anthropic сообщает, что их модель Claude после первоначальной подсказки создала рабочий эксплойт для удалённого получения root. Путь от утечки указателя ядра до root-шелла занял меньше часа машинного времени. Они его не опубликовали, и скептики на HN повеселились над фразой «поверьте на слово». Справедливо. Но даже с учётом маркетинговой поправки направление очевидно: время между «диф попал в стабильную ветку» и «рабочий эксплойт существует» сокращается, потому что узким местом написания эксплойтов никогда был сам баг. Узким местом был человек, который мог прочитать диф и провести heap grooming.

Это сжимает окно решения «патч или митигация». Когда разработка эксплойта занимала недели, фраза «митигируем сейчас, патчим в следующем окне обслуживания» была оправдана. Когда модель может за ночь выдать PoC по публичному коммиту, фаза митигации должна измеряться часами, а фаза патча — днями. Четырёхстрочный фикс открыт, его может изучить любой. Исходите из того, что эксплойт тоже доступен.

Моя рекомендация

Патчите. Митигацию используйте только как мост и поставьте на мост срок годности. Конкретно: если у вашего дистрибутива есть исправленное ядро, начните раскатку сейчас и проверяйте uname -r после каждой перезагрузки. Если вы на Ubuntu или RHEL, сегодня же разверните отбрасывание IP-опций и отключите MPTCP, а отсутствие исправления ядра считайте блокирующей зависимостью: проверяйте трекер ежедневно, а не раз в неделю. В первую очередь займитесь всем, что смотрит в интернет и имеет MPTCP-листенер, затем всем остальным, что принимает входящий TCP, а это почти всё. Контейнеры вас не спасут: они делят ядро с хостом, так что патчите ноды.

Более глубокий урок — тот, который эта уязвимость преподаёт раз в несколько лет под новым номером CVE: митигации покупают время, но закрывают дыры только патчи, и время, которое покупают митигации, становится всё короче. Нарабатывайте навык быстрых и безопасных раскаток ядра заранее, пока он не понадобился, ведь следующий четырёхстрочный фикс уже лежит в чьей-то очереди.