Ubuntu не выпустила патч для 0day RCE в ядре Linux

Обсуждение на Hacker News о задержке патча для критической уязвимости RCE в ядре Linux. Ubuntu не выпустила исправление почти три недели.

Что известно о уязвимости

В обсуждении на Hacker News упоминается CVE-2026-98432 — уязвимость типа удалённого выполнения кода (RCE) в ядре Linux. На момент написания патча от Ubuntu нет уже почти три недели. Для администратора это не повод для паники, но повод проверить, какие ядра запущены в инфраструктуре, и понять, какие векторы атаки реальны. Подробнее о задержке можно прочитать в материале Задержка патча Ubuntu для 0day RCE в Linux.

CVE-2026-98432 и механизм эксплуатации

Конкретные детали уязвимости в открытом доступе пока ограничены, поэтому судить о точном механизме эксплуатации можно только по косвенным признакам из обсуждения. RCE в ядре означает, что злоумышленник может выполнить код с привилегиями ядра — кольцо ноль, полный контроль над хостом.

Во-первых, нужно понять, затронута ли ваша система. Проверьте версию ядра:

bash
uname -r

В Ubuntu также можно посмотреть подпись ядра:

bash
cat /proc/version_signature

Если вывод содержит уязвимую ветку, система находится под угрозой. Сравните версию со списком исправленных в официальном бюллетене безопасности Ubuntu — пока патча нет, список может быть пустым, но отслеживать обновления нужно через Ubuntu Security Notices.

С практической точки зрения, механизм эксплуатации таких уязвимостей обычно сводится к отправке специально сформированного сетевого пакета или вызову уязвимого системного вызова из пользовательского пространства. Без публичного эксплойта сложно судить о простоте атаки, но отсутствие патча три недели — это уже инцидент для продакшена.

Почему это критично для серверов

Уязвимость в ядре критичнее, чем уязвимость в прикладном приложении, по одной простой причине: ядро — это граница доверия. Если злоумышленник выполняет код в кольце ноль, никакие контейнеры, сетевые экраны или изоляция приложений не спасут.

Для домашних серверов и продакшена риски одинаковы:

Полная компрометация хоста. Злоумышленник получает root, может установить бэкдор, изменить ядро или перехватить трафик.
Побег из контейнера. Если уязвимый сервер запускает Docker или LXC, компрометация ядра означает выход из любого контейнера на хост.
Уклонение от мониторинга. Код на уровне ядра может скрыть процессы, сетевые соединения и изменения файлов от инструментов наблюдения в пользовательском пространстве.

Проверить, какие службы слушают сетевые интерфейсы, можно так:

bash
ss -tulpn

Если на сервере открыты сервисы, принимающие вход извне (SSH, веб-сервер, API), поверхность атаки велика. Даже если сервер находится за NAT, одна скомпрометированная рабочая станция в локальной сети достаточно для атаки на ядро.

Вот почему задержка с патчем почти три недели — это не «забыли выпустить обновление», а реальное окно уязвимости. В это время нужно ограничить доступ к уязвимым интерфейсам, проверить правила брандмауэра и быть готовым к экстренному обновлению, как только Canonical выпустит исправление. Если ещё не настроили процесс оперативного обновления ядра, стоит посмотреть базовые инструменты и практику в материале Skills for Real Engineers: Инструменты и практика.

Позиция Ubuntu и Canonical

Отсутствие патча в репозиториях

Когда в ядре Linux находится критическая уязвимость с удалённым выполнением кода, ожидание патча измеряется не днями, а часами. Ubuntu почти три недели не публиковала исправление в своих репозиториях, и это создаёт реальное окно для эксплуатации.

С точки зрения инженера, проблема не в самом задержке — upstream-фикс проходит через тестирование, сборку и верификацию под разные архитектуры. Проблема в отсутствии прозрачности. Canonical не опубликовала чёткого графика, не объяснила, почему пакет linux-image не обновляется, и не предложила временного обходного пути для пользователей обычной Ubuntu (не Pro).

Проверьте, что у вас установлено:

bash
uname -r
apt list --installed | grep linux-image

Если версия ядра уязвимая, а в apt нет обновления, у вас ограниченный набор вариантов:

Собрать ядро из upstream-источника вручную — надёжно, но отнимает время и требует поддержки.
Подключить Ubuntu Pro и использовать Livepatch — работает только на поддерживаемых версиях и не всегда покрывает свежие 0day.
Перейти на другой дистрибутив временно — радикально, но иногда быстрее, чем ждать Canonical.

Я предпочитаю первый вариант для критичных серверов: лучше потратить вечер на сборку ядра с патчем, чем надеяться на репозиторий, который молчит три недели. Предсказуемость конфигурации важнее удобства автоматических обновлений.

Связанные материалы:

Что говорит Hacker News

Обсуждение на Hacker News разделилось на два лагеря. Одни критикуют Canonical за молчание и за то, что исправление доступно только подписчикам Ubuntu Pro. Другие напоминают, что дистрибутив — не гарантия мгновенного патча, и что любой администратор должен уметь собирать ядро самостоятельно.

В комментариях часто упоминают Debian: у них пакет linux-image обновился быстрее, потому процесс сборки менее бюрократизирован. Также звучат сравнения с RHEL, где есть чёткие SLA на безопасность. Из полезного — ссылки на коммиты в upstream и советы по временному снижению риска через сетевые экраны и отключение уязвимого интерфейса.

С практической точки зрения, Hacker News полезен не как источник официальной позиции Canonical, а как индикатор того, как быстро сообщество находит обходные пути. Если в треде появляются готовые конфиги iptables или nftables для блокировки вектора атаки, стоит посмотреть внимательнее.

Пример простого ограничения входящего трафика на подозрительный порт (замените на актуальный для вашей уязвимости):

bash
sudo iptables -A INPUT -p tcp --dport 445 -j DROP
sudo netfilter-persistent save

Не воспринимайте это как панацею. Сетевой экран снижает поверхность атаки, но не заменяет патч ядра.

Окончательный вывод: позиция Ubuntu в этой ситуации — реактивная, а не проактивная. Для продакшена я рекомендую не полагаться на один репозиторий и иметь план по самостоятельной сборке ядра или миграции на дистрибутив с более строгими SLA по безопасности.

Что делать администраторам прямо сейчас

Временные меры снижения риска

Пока патча нет, единственный способ снизить риск — сузить поверхность атаки. Я не сторонник «затыкать дыры скотчем», но когда вендер задерживается, временные ограничения — это нормальная инженерная практика.

Во-первых, ограничьте сетевой доступ к хосту. Если сервер не должен быть доступен извне, закройте всё, кроме необходимого порта. Пример с nftables:

nftables
table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        iifname "lo" accept
        ct state established,related accept
        ip protocol icmp accept
        tcp dport 22 ip saddr 10.0.0.0/8 accept
        tcp dport 80,443 accept
    }
}

С практической точки зрения: правило policy drop по умолчанию лучше, чем попытка угадать все опасные порты. Оставьте только то, что действительно нужно.

Во-вторых, ограничьте локальный доступ. RCE в ядре часто требует возможности выполнить код в пространстве пользователя. Если на хосте работают контейнеры, не давайте им привилегированный доступ без необходимости. Проверьте, нет ли в системе лишних пользователей с правом sudo:

bash
grep -E '^sudo|^admin' /etc/group

Если на сервере нет необходимости в загрузке произвольных модулей ядра, запретите это через sysctl:

bash
# /etc/sysctl.d/99-kernel-hardening.conf
kernel.modules_disabled = 1

Применить:

bash
sysctl --system

Имейте в виду: после этого нельзя будет загружать модули без перезагрузки. Это компромисс между безопасностью и гибкостью.

В-третьих, если у вас есть возможность использовать live-patching, включите его. Это не заменит полноценный патч, но закроет известные уязвимости без перезагрузки. Когда Ubuntu выпустит обновление — например, как описано в материале Ubuntu не выпустила патч для 0day RCE в ядре Linux — применяйте его в первую очередь. Временные ограничения не заменяют исправления.

Мониторинг и обнаружение эксплуатации

Ограничения снижают вероятность эксплуатации, но не исключают её. Нужно знать, если атака всё же произошла.

Начните с системного лога. Ядро пишет критические ошибки в journald, и первые признаки эксплуатации часто выглядят как необычные oops или panic:

bash
journalctl -k -p err --since "2 hours ago"

Если видите повторяющиеся BUG: unable to handle kernel paging request или general protection fault — это повод проверить хост вручную.

Для более глубокой видимости настройте auditd. Пример правила на отслеживание опасных системных вызовов, которые часто используются в эксплойтах ядра:

bash
# /etc/audit/rules.d/kernel.rules
-a always,exit -F arch=b64 -S ptrace -F auid>=1000 -F auid!=4294967295 -k kernel_ptrace
-a always,exit -F arch=b64 -S mount -F auid>=1000 -F auid!=4294967295 -k kernel_mount

После добавления правил перезагрузите auditd:

bash
augenrules --load

Следите за загрузкой незнакомых модулей ядра. В Proxmox или на обычном Ubuntu это можно отследить через lsmod и сравнивать с эталоном, но лучше автоматизировать. Например, простой скрипт, который проверяет lsmod и шлёт алерт, если появился неизвестный модуль.

На уровне инфраструктуры я используем Prometheus с node_exporter и Alertmanager. Метрика node_uname_info не поможет обнаружить эксплойт, но сочетание с node_load1 и количеством процессов в состоянии D (непрерывный сон) может косвенно указать на проблемы в ядре. Пример правила оповещения:

yaml
groups:
- name: kernel_anomalies
  rules:
  - alert: HighUninterruptibleProcesses
    expr: sum(node_procs_state{state="D"}) > 50
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Много процессов в состоянии D на {{ $labels.instance }}"
      description: "Возможны проблемы с ядром или файловой системой."

Если хотите более целевого решения для обнаружения эксплуатации в реальном времени, посмотрите в сторону Falco или Tetragon. Они работают на базе eBPF и могут сработать на подозрительные системные вызовы из контейнеров или необычное поведение ядра. Это уже не «решение на коленке», а полноценный компонент безопасности, который стоит документировать и поддерживать. Подробнее про инструменты и подходы можно почитать в материале Skills for Real Engineers: Инструменты и практика.

Все эти меры дают предсказуемость: вы знаете, что происходит на хосте, даже когда вендер задерживает патч.

Долгосрочные выводы для инфраструктуры

Три недели без патча для критической уязвимости RCE в ядре Linux — это не задержка релиза, а тревожный сигнал. Когда вендор не успевает (или не хочет) оперативно закрыть 0day, ответственность за безопасность остаётся на инженере, который держит сервер в сети. Ниже два раздела, которые я вынес для себя после обсуждения на Hacker News и связанных с ним материалов: Патч для 0day RCE в ядре Linux всё ещё не выпущен Ubuntu.

Политика обновлений ядра

Во-первых, я перестал полагаться на график обновлений дистрибутива как на единственный источник правды. Ubuntu, Debian, RHEL — у всех свои процессы сборки, тестирования и выпуска. Для интернет-узла три недели ожидания патча ядра — это окно эксплуатации, которое нельзя игнорировать. Это примерно как оставить дверь в подъезд открытой на ночь и надеяться, что никто не зайдёт.

С практической точки зрения я выработал такие правила:

Ядро обновляется отдельно от остальных пакетов. Автоматические обновления безопасности включаю, но ядерные пакеты добавляю в чёрный список unattended-upgrades, чтобы не получить неожиданную перезагрузку в рабочее время.
Новое ядро сначала катится на стенде или на одной некритичной ноде. Если через сутки нет регрессов — распространяю на остальные.
Обязательно сохраняю предыдущее ядро в GRUB и проверяю, что загрузка с него работает. apt-mark hold помогает не потерять рабочую версию.
Для критичных серверов смотрю в сторону Canonical Livepatch — он закрывает окно между выпуском патча и перезагрузкой, но не заменяет полное обновление.

Пример конфига unattended-upgrades, который я использую на своих серверах:

bash
# /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    "${distro_id}:${distro_codename}-updates";
};
Unattended-Upgrade::Package-Blacklist {
    // Ядро обновляем вручную после тестирования
    "linux-image";
    "linux-headers";
    "linux-modules";
    "linux-tools";
};
Unattended-Upgrade::Automatic-Reboot "false";

После установки проверяю, требуется ли перезагрузка:

bash
$ ls /var/run/reboot-required

Если файл есть — планирую ребут в окне обслуживания, а не жду, пока система сама решит, когда перезагрузиться.

Предсказуемость конфигурации для меня важнее скорости развёртывания. Лучше отложить обновление на день и проверить его на стенде, чем получить панику ядра в продакшене в три часа ночи.

Изоляция и микросегментация

Уязвимость RCE в ядре означает выполнение кода с привилегиями ядра. В этот момент сетевой периметр становится последним рубежом, который ещё может остановить атакующего. Я не доверяю локальной сети просто потому, что она «внутренняя».

Во-первых, я разделяю плоскости управления и данных. IPMI, iDRAC, SSH для администрирования — на отдельном VLAN или физическом интерфейсе, который не маршрутизируется в общую сеть сервисов.

Во-вторых, между нодами кластера разрешаю только то, что действительно нужно. Пример nftables для узла, который не должен принимать лишний трафик от соседей:

nft
table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        iifname "lo" accept
        ct state established,related accept
        ip protocol icmp accept
        tcp dport 22 accept
        tcp dport 9100 accept  # мониторинг
        tcp dport 6443 accept  # Kubernetes API, только если нужен
        # всё остальное — drop
    }
    chain forward {
        type filter hook forward priority 0; policy drop;
        // микросегментация: только нужные сервисы между подсетями
        ip saddr 10.0.0.0/24 ip daddr 10.0.1.0/24 tcp dport 5432 accept
        ip saddr 10.0.0.0/24 ip daddr 10.0.1.0/24 tcp dport 6379 accept
    }
}

В Docker я не публикую порты наружу без необходимости и использую внутренние сети. Если один контейнер скомпрометирован через ядерную уязвимость, он не должен иметь прямого доступа к хранилищу или гипервизору.

Пример сетевой конфигурации через netplan с выделением VLAN для управления:

yaml
network:
  version: 2
  ethernets:
    eno1:
      addresses:
        - 10.0.0.10/24
    eno2:
      addresses:
        - 192.168.1.10/24
  vlans:
    mgmt:
      id: 100
      link: eno1
      addresses:
        - 10.100.0.10/24

Связь между задержкой патча и изоляцией проста: пока ждёте исправления от Ubuntu, микросегментация даёт время. Задержка патча Ubuntu для 0day RCE в Linux показала, что даже крупные дистрибутивы могут простоять недели без фикса. Ваша сеть должна быть готова к этому.

Часто задаваемые вопросы

Можно ли снизить риск эксплуатации, пока Ubuntu не выпустила патч?

С практической точки зрения, можно ограничить сетевой доступ куязвимому интерфейсу через nftables или iptables, если вектор атаки сетевой. Например, если уязвимость проявляется при обработке пакетов наопределённом порту, закройте этот порт навнешнем интерфейсе. Это не заменит патч, но даст время на тестирование обновления встенде.

Нужно ли пересобирать ядро вручную, чтобы получить исправление быстрее?

Пересборка ядра из исходников Linux возможна, но для продакшена это плохая идея: вы потеряете подписанные модули, Secure Boot и поддержку от Ubuntu. Если патча нет, лучше использовать ядро из бэкпортов или подождать официального обновления, чем собирать неопробованную сборку на`рабочих серверах.

Как проверить, что моя система уязвима, если версия ядра совпадает с подозрительной?

Команда uname -r показывает только версию, но не наличие бэкпортированных исправлений. Посмотрите вывод cat /proc/version_signature и сравните его со списком уязвимых сборок вбюллетене безопасности Ubuntu. Если ввыводе есть уязвимая ветка, система требует внимания, даже если патч ещё не вышел.

Стоит ли переходить на другой дистрибутив из-за задержки с патчем?

Смена дистрибутива из-за одной задержки — решение эмоциональное, а не инженерное. Если ваша инфраструктура построена наUbuntu, проще выстроить процесс мониторинга Ubuntu Security Notices и оперативно применять патч, когда он появится. Предсказуемость инфраструктуры важнее смены ОС нафоне одного инцидента.

Что делать, если сервер уже скомпрометирован через эту уязвимость?

Если есть подозрение наэксплуатацию, изолируйте хост отсети и сохраните дамп памяти и логи ядра черезjournald для анализа. Переустановите систему снуля, не доверяя текущему состоянию ядра и модулей. После переустановки настройте алерты вPrometheus на аномальную активность вядре, чтобы не пропустить повторное заражение.

Ubuntu не выпустила патч для 0day RCE в ядре Linux