CVE-2026-98432 затрагивает обработку TCP/IPv4 в ядре Linux. Если у тебя сервер на Ubuntu, проверь ветку ядра и доступность исправления для неё. На 30 октября 2026 года основные ветки linux в Ubuntu всё ещё отмечены как уязвимые; работа над обновлениями продолжается. Текущий статус Canonical.
Ниже — порядок проверки для владельца VPS или администратора. Команды обновления выполняй на своей Ubuntu-машине; они меняют пакеты, а перезагрузка прерывает работу сервисов.
Что произошло в ядре Linux
Ошибка относится к use-after-free: код продолжает читать память после её освобождения. При параллельной обработке повторного TCP SYN один процессор ещё использует опции сокета, пока другой уже освобождает их. Похожая гонка возникает при миграции запросов между сокетами.
В исправлении Linux e3f33b0 немедленное освобождение памяти заменили на kfree_rcu(). Оно откладывает освобождение до момента, когда читатели закончат работу. Наличие этого коммита в upstream само по себе не означает, что твой дистрибутив уже выпустил обновление.
Насколько опасна CVE-2026-98432
В карточке Ubuntu указаны две оценки: 9.8 по CVSS 3.1 и 8.3 по CVSS 4.0, приоритет Canonical — High. У оценок разные модели; сравнивать их как одну шкалу «вчера было хуже, сегодня стало лучше» нельзя. Оценки Ubuntu.
Red Hat описывает основной возможный эффект как падение системы с отказом в обслуживании или повреждение памяти. Сетевой вектор означает, что проблема заслуживает внимания владельцев доступных по сети Linux-систем.
В проверенных первоисточниках нет подтверждения, что твой сервер уже взломан, что идут массовые атаки или что существует гарантированный удалённый root. Балл CVSS не доказывает ни одно из этих событий. При этом откладывать проверку сервера до появления новостей о взломах тоже не стоит.
Какие Ubuntu затронуты и готов ли патч
Срез карточки Canonical на 30 октября 2026 года, пакет linux:
| Выпуск Ubuntu | Статус |
|---|---|
| 26.10 | Уязвим, исправление готовится |
| 26.04 LTS | Уязвим, исправление готовится |
| 24.04 LTS | Уязвим, исправление готовится |
| 22.04 LTS | Уязвим, исправление готовится |
Источник таблицы — Ubuntu CVE Tracker. Для HWE, AWS, Azure и других вариантов смотри отдельную строку своего пакета. Этот список не исчерпывает все затронутые системы.
Статус work in progress означает подготовку исправления. Номер планируемой сборки рядом с ним нельзя выдавать за уже выпущенный безопасный пакет. Canonical объясняет состояния пакетов в справке о CVE.
Как проверить свой сервер
1. Узнай систему и запущенное ядро
Эти команды только читают сведения:
cat /etc/os-release
uname -r
dpkg-query -W -f='${binary:Package}\t${Version}\n' "linux-image-$(uname -r)"
os-release показывает выпуск системы, uname -r — работающее ядро, последняя команда — полную версию соответствующего установленного пакета. Сохрани результат для сверки с карточкой CVE. Формат ${Version} оставь в одинарных кавычках. Документация os-release, uname, dpkg-query.
Если dpkg-query не находит пакет, это не доказывает безопасность. Так бывает с нестандартным ядром или внутри контейнера. Выясни, какое ядро обслуживает хост и кто отвечает за его обновления.
2. Проверь именно свою ветку
Открой карточку CVE, найди выпуск Ubuntu и вариант ядра. Для решения об исправлении нужны статус выпущенного пакета и его полная версия. Одних цифр вроде 6.8 недостаточно: дистрибутив может переносить патч в свою ветку, сохраняя основную версию ядра. О такой практике рассказывает Red Hat.
Если сервер управляется хостером, отправь ему номер CVE и попроси подтвердить пакет с исправлением и порядок его применения. Для контейнерного сервиса вопрос относится и к хосту, на котором он работает.
3. Установи доступные обновления
Перед изменениями на рабочем сервере проверь резервную копию, доступ к консоли провайдера и окно обслуживания. Затем обнови индексы и установленные пакеты из настроенных доверенных репозиториев:
sudo apt update
sudo apt upgrade
Прочитай список предлагаемых изменений перед подтверждением. Это штатный порядок из документации Ubuntu. Если ядро удержано или обновление не предлагается, разбери причину с администратором.
Когда фикс ещё готовится, эти команды не могут установить отсутствующий патч. После обновления снова сверь статус CVE и версию пакета. Canonical рекомендует обновлять систему штатно, а не выбирать случайные патчи вручную. Установка mainline RC ради одного коммита на рабочем сервере требует отдельного тестирования и плана отката.
4. Примени новое ядро и проверь результат
После установки исправленного ядра запланируй перезагрузку. Сначала заверши важные операции и предупреди тех, кто пользуется сервисами. Когда окно обслуживания началось:
sudo reboot
После возвращения сервера повтори uname -r и dpkg-query из первого шага. Установленный пакет и запущенное ядро должны соответствовать исправленной сборке. Автоматическая установка обновлений не гарантирует автоматическую перезагрузку: её поведение задаётся отдельно в настройках Ubuntu.
Что делать, пока исправление готовится
Моя рекомендация по снижению доступности лишних сервисов:
- Убери из публичного доступа ненужные TCP-порты. Административные интерфейсы ограничь доверенными адресами или VPN.
- Проверь правила внешнего firewall или security group у провайдера. Перед изменением сохрани доступ к консоли, чтобы не отрезать себе SSH.
- Зафиксируй версию ядра, ответственного за обновление и ближайшую проверку статуса CVE. Для управляемого сервиса запроси ответ у провайдера.
Это общие меры сокращения поверхности атаки, их эффективность против конкретной CVE здесь не проверялась. Механика ограничения по портам и адресам описана в документации Ubuntu Firewall. В карточке Red Hat на дату проверки нет универсального обходного решения, соответствующего критериям вендора.
Частые вопросы
Достаточно отключить tcp_migrate_req?
Нет оснований считать это полным исправлением. В upstream описан и отдельный сценарий с повторной обработкой SYN. Изменение параметра миграции не устраняет его. Описание разработчиков ядра.
Достаточно обновить Docker-образ?
Для ошибки ядра нужно проверить хост. В обычной контейнерной конфигурации контейнер использует его ядро; замена пользовательского окружения внутри образа не подтверждает применение исправления на хосте. Устройство контейнеров описано в документации Docker.
Можно считать сервер защищённым после apt upgrade?
Только после проверки, что для твоего пакета выпущено исправление и оно применяется к работающему ядру. Успешное завершение команды обновления само по себе этого не подтверждает.
Статусы в статье проверены 30 октября 2026 года. Перед действиями открой актуальную карточку Ubuntu CVE-2026-98432: после публикации материала состояние пакетов может измениться.