Уязвимость в стеке IPv4 ядра Linux открывает путь к удалённому отказу в обслуживании в Ubuntu, RHEL и Debian

Ядро Linux содержит уязвимость использования памяти после освобождения в сетевом стеке IPv4. Ошибка позволяет удалённому злоумышленнику вывести машину из строя, причём без учётных данных и без доступа к самой системе. В перечень затронутых продуктов попали ядро Linux в версиях от 4.4 до 7.3, сборки Ubuntu от 14.04 до 26.10, Red Hat Enterprise Linux 8, 9 и 10, Debian GNU/Linux 12 и 13, а также контейнерная платформа Red Hat OpenShift Container Platform версий 4 и 5. Оценка по CVSS 3.1 достигает 9,8 из 10, по CVSS 2.0 - 10 из 10. Банк данных угроз безопасности информации (BDU) относит проблему к критическому уровню опасности. Рабочий эксплойт уже выложен в открытый доступ.

CVE-2026-98432 в стеке IPv4 ядра Linux

Сбой кроется в коде, который создаёт сокет при установлении входящего TCP-соединения. Сокет освобождается, а обработчик продолжает обращаться к его памяти. Сторонний отправитель специально собранных пакетов запускает цепочку, в которой ядро читает и меняет уже освобождённый участок. Использование памяти после освобождения (CWE-416) означает работу с областью, содержимое которой могли перезаписать другие данные. Результат предсказуем - сбой ядра и остановка узла.

Описание в BDU называет следствием отказ в обслуживании. Вектор CVSS при этом формально предполагает высокое влияние на конфиденциальность, целостность и доступность. Полного сценария с выполнением кода в открытых данных нет, поэтому расчётной остаётся именно недоступность сервиса. Дата выявления - 1 октября 2026 года, производители проблему подтвердили.

Дистрибутивы и контейнерная платформа

Дистрибутивы наследуют ошибку от ядра, отсюда широкий список сборок. У Canonical в перечне значатся релизы Ubuntu с длительной поддержкой от 14.04 до 26.10. У Red Hat - три мажорные ветки корпоративной системы. У сообщества Debian - текущая и предыдущая версии. Уязвимы и три диапазона самого ядра: от 4.4.0 до 6.12.113, от 6.18.0 до 6.18.56 и от 7.2.0 до 7.2.10.

Отдельный риск создаёт OpenShift Container Platform. Контейнеры делят ядро хоста, поэтому сбой узла задевает все рабочие нагрузки на нём. Для кластеров с плотной упаковкой сервисов это означает не потерю одного пода, а простой целого сегмента платформы. Долгие циклы поддержки добавляют сложности: старые LTS-сборки остаются в списке затронутых, хотя обновления для них выходят реже.

Публичный эксплойт меняет приоритеты

Готовая реализация атаки на GitHub сокращает время между раскрытием деталей и попытками эксплуатации. Сетевой вектор не требует ни пароля, ни действий пользователя. Достаточно достучаться до уязвимого узла по сети. Пограничные серверы и хосты с опубликованными сервисами оказываются в первой группе риска. Внутренние сегменты тоже не защищены автоматически: ошибка срабатывает на уровне ядра, поэтому её нельзя закрыть настройкой отдельного приложения.

Исправления и порядок действий

Производители подготовили патчи в стабильных ветках ядра. Статус уязвимости в BDU - подтверждена производителем и устранена. Ссылки на исправления ведут в репозиторий ядра, а также в трекеры безопасности Red Hat, Debian и Ubuntu.

Администраторам стоит обновить ядро до актуальной сборки своего дистрибутива. В Ubuntu, RHEL и Debian для этого достаточно штатного менеджера пакетов после обновления списка репозиториев. В OpenShift обновляют узлы кластера вместе с платформой, иначе новые контейнеры продолжат работать на уязвимом ядре. Если исправленной сборки для используемой версии нет, примените рекомендации ФСТЭК России по безопасной настройке операционных систем Linux от 25 декабря 2022 года. Дополнительно ограничьте сетевой доступ к уязвимым узлам со стороны недоверенных сетей и изолируйте те хосты, где обновление откладывается.

История с CVE-2026-98432 показывает слабое место общей модели распространения Linux: одна ошибка в ядре расходится по десяткам дистрибутивов и платформ, а сроки установки патчей зависят от каждого вендора. Публичный эксплойт и рейтинг 9,8 оставляют немного времени на манёвр. Быстрее всех закрываются те, кто заранее знает свой парк ядер и версии узлов контейнерных кластеров.