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

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

Разбираем ситуацию с неисправленной уязвимостью в ядре Linux, которая уже почти три недели не имеет патча в Ubuntu, и что с этим делать администраторам.

Что известно об уязвимости и задержке с патчем

Что известно об уязвимости и задержке с патчем

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

Ситуация не новая, но неприятная. Я сам сталкивался с задержками патчей в Ubuntu — когда уязвимость уже обсуждается на рассылках, а в apt всё ещё старый пакет. Системный подход к администрированию, о котором я писал ранее Навыки для настоящих инженеров: коллекция из .agents, здесь как никогда кстати. Ниже разберём, что именно известно о CVE-2026-98432, и почему Canonical тянет с выпуском обновления.

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

Согласно информации из рассылки ядерных разработчиков kernel.org, уязвимость находится в подсистеме управления памятью ядра при работе с сетевыми сокетами. Ошибка позволяет локальному пользователю повысить привилегии до root, а при наличии доступа к сетевому интерфейсу — потенциально выполнить код удалённо. Точный вектор атаки Canonical пока не раскрыла, но из описания следует, что достаточно отправить специально сформированный пакет или воспользоваться уязвимым системным вызовом из пользовательского пространства.

Если мы посмотрим на типичную цепочку эксплуатации, она выглядит так:

1. злоумышленник получает доступ к оболочке сервера (через SSH, веб-приложение или уязвимость в другом сервисе);
2. запускает exploit, который вызывает использование освобождённой памяти (use-after-free) в контексте ядра;
3. получает выполнение кода с правами root и полный контроль над хостом.

Проверить версию ядра на своих серверах можно так:

bashКопировать
uname -r
dpkg -l | grep linux-image

Пример вывода:

textКопировать
6.8.0-50-generic
ii  linux-image-6.8.0-50-generic  6.8.0-50.50~22.04.1  amd64

Если версия попадает в уязвимый диапазон, сервер требует внимания. Пока патча нет, я рекомендую ограничить локальный доступ к машине, отключить неиспользуемые сетевые сервисы и проверить правила межсетевого экрана. На моём сервере Винни-Пух я временно закрыл все порты, кроме 22 и 443, и оставил только ключевой доступ по SSH с фиксированных адресов.

Почему Canonical не выпустила обновление

Задержка в три недели для ядра Linux в Ubuntu — не аномалия, а стандартный процесс. Canonical следует процедуре SRU (Stable Release Updates): исправление должно пройти triage, сборку под все поддерживаемые ароматы ядра (generic, lowlatency, облачные варианты для AWS, Azure и других) и проверку на регрессии. Когда речь идёт о ядре, ошибка в патче может положить всю систему, поэтому тестирование занимает время.

Во-вторых, Canonical часто ждёт официального исправления от сообщества ядерных разработчиков на kernel.org. Если upstream-патч ещё не готов или требует доработки под стабильную ветку Ubuntu, команда безопасности не выпустит «костыль» просто для галочки. Это правильный подход, но для администратора он означает простой в ожидании.

Ещё один нюанс — модели поддержки. Некоторые исправления сначала попадают в Ubuntu Pro (ESM), а затем в общедоступные репозитории. Если ваши серверы работают на Ubuntu LTS без подписки Pro, вы можете остаться без патча дольше, чем платные клиенты Canonical.

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

bashКопировать
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

И добавьте в /etc/apt/apt.conf.d/50unattended-upgrades:

textКопировать
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};

Если уязвимость критична и ждать нельзя, можно попробовать собрать ядро из основной ветки (mainline), но для production это путь без гарантий и без поддержки Canonical. Лучше ограничить поверхность атаки, включить мониторинг и быть готовым к экстренному перезапуску сервисов, как только патч появится.

Как проверить, уязвима ли ваша система

Как проверить, уязвима ли ваша система

Когда патча ещё нет, главное — не паника, а точное понимание своего положения. Если уязвимость в ядре Linux не закрыта в Ubuntu, вы должны знать, какая версия ядра запущена на каждом сервере и какие пакеты могут быть обновлены, когда патч выйдет. Ниже — порядок действий, который я использую сам, когда нужно быстро оценить парк машин. Это часть системного подхода, о котором я писал ранее: Навыки для настоящих инженеров: коллекция из .agents.

Проверка версии ядра в Ubuntu

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

Во-первых, команда uname показывает версию запущенного ядра:

bashКопировать
uname -r

Пример вывода:

6.5.0-27-generic

Здесь 6.5.0 — версия ядра, 27 — номер сборки Ubuntu, generic — flavour для рабочих станций и серверов общего назначения. Если на сервере стоит ядро lowlatency или aws, суффикс будет другим, но принцип проверки тот же.

С практической точки зрения, uname -r говорит только о том, что загружено в данный момент. Чтобы увидеть полную строку версии, включая компилятор и архитектуру, используйте:

bashКопировать
cat /proc/version

Или более читаемый вариант через hostnamectl:

bashКопировать
hostnamectl | grep Kernel

Вывод будет примерно таким:

  Kernel: Linux 6.5.0-27-generic

Если нужно проверить, какие пакеты ядра установлены в системе (а не только запущены), посмотрите через dpkg:

bashКопировать
dpkg -l | grep linux-image

Пример вывода:

ii  linux-image-6.5.0-27-generic   6.5.0-27.27~22.04.1   amd64   signed kernel image generic
ii  linux-image-generic-hwe-22.04  6.5.0.27.27~22.04.15  amd64   Generic Linux kernel image

Вторая строка — мета-пакет. Он тянет за собой актуальное ядро в рамках HWE-стека. Если патч выйдет, именно этот пакет потянет новую версию, поэтому важно, чтобы он не был удалён или заморожен.

Аудит установленных пакетов

Знание версии запущенного ядра — только половина дела. Нужно понимать, какие пакеты ядра установлены в системе, не обновляются ли они и не заблокированы ли обновления на уровне APT.

Во-первых, посмотрите все пакеты, связанные с ядром:

bashКопировать
dpkg -l | grep -E 'linux-image|linux-headers|linux-modules'

Обратите внимание на флаг в первой колонке: ii означает, что пакет установлен и настроен. Если видите rc — пакет удалён, но остались конфигурационные файлы; iU или iH — проблемы с установкой или удержанием.

Далее проверьте, нет ли удержанных пакетов. Если ядро заморожено через apt-mark, обновления безопасности не применятся, даже когда патч выйдет:

bashКопировать
apt-mark showhold

Пример вывода, если ядро удержано:

linux-image-generic-hwe-22.04
linux-headers-generic-hwe-22.04

Если в списке есть пакеты ядра, снимите удержание, когда будете готовы обновляться:

bashКопировать
sudo apt-mark unhold linux-image-generic-hwe-22.04

С практической точки зрения, полезно проверить, есть ли в репозиториях более новая версия ядра, чем установлена. Обновите индекс пакетов и посмотрите доступные обновления:

bashКопировать
sudo apt update
apt list --upgradable 2>/dev/null | grep linux-image

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

Когда патч выйдет, порядок обновления будет стандартным: sudo apt update && sudo apt upgrade, затем перезагрузка. До тех пор ограничьте доступ к уязвимым сервисам и проверяйте логи на подозрительную активность.

Что делать, если патча ещё нет

Что делать, если патча ещё нет

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

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

Во-первых, ограничьте входящий трафик только тем, что действительно нужно. Если уязвимость проявляется через сетевой стек, закрытие лишних портов на границе снижает вероятность эксплуатации.

bashКопировать
# ufw: по умолчанию запрет всего входящего, открыто только необходимое
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

С практической точки зрения, ненужные модули ядра лучше выгрузить, чем оставить «на всякий случай». Каждый загруженный драйвер — дополнительный вектор атаки.

bashКопировать
# Посмотреть, что загружено
lsmod

# Выгрузить модуль — делайте это только после тестирования на стенде
sudo modprobe -r имя_модуля

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

bashКопировать
# /etc/modprobe.d/blacklist-local.conf
blacklist имя_модуля
install имя_модуля /bin/false

Если инфраструктура позволяет, подключите Canonical Livepatch — для до трёх машин бесплатно, патчи применяются без перезагрузки. Это не замена полному обновлению, но даёт время спланировать работы.

Если мы посмотрим на подход к подобным инцидентам, систематическое сужение поверхности атаки работает лучше, чем надежда на то, что уязвимость не заметят. Подробнее про инженерный подход — в коллекции Навыки для настоящих инженеров: коллекция из .agents.

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

Без патча дыру не закроешь, но можно заметить, что в нее лезут, пока атакующий не закрепился в системе.

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

bashКопировать
# Установка на Ubuntu
sudo apt install auditd

# Пример правила: отслеживание подозрительного системного вызова
sudo auditctl -a always,exit -F arch=b64 -S имя_системного_вызова -k уязвимость_ядра

Перенаправьте логи в Loki или Elasticsearch и поднимите алерт в Alertmanager на рост событий с тегом уязвимость_ядра.

yamlКопировать
# Пример правила для Prometheus + Alertmanager
groups:
  - name: kernel_exploit_attempts
    rules:
      - alert: KernelExploitAttempt
        expr: increase(auditd_events_total{tag="kernel_rce"}[5m]) > 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Обнаружены попытки эксплуатации уязвимости в ядре"
          description: "На {{$labels.instance}} за последние 5 минут зафиксировано {{$value}} подозрительных системных вызовов."

Смотрите также journald — ядро пишет туда предупреждения при некорректных пакетах или попытках доступа к запрещённой памяти.

bashКопировать
# Сообщения ядра за последний час
journalctl -k --since "1 hour ago"

# Отфильтровать по тревожным ключевым словам
journalctl -k | grep -i "oops\|panic\|call trace"

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

Долгосрочная стратегия обновления ядер

Долгосрочная стратегия обновления ядер

Когда в ядре Linux находится «0day RCE», а в репозиториях Ubuntu патча всё ещё нет — это не повод переустанавливать серверы в панике, но и не повод ждать, пока что-то само собой исправится. Три недели без обновления — это достаточно долго, чтобы пересмотреть подход к обновлениям ядра на постоянной основе. Ниже опишу, как я выстроил этот процесс на своих серверах и что рекомендую клиентам.

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

Автоматизация обновлений через unattended-upgrades

В Ubuntu обновления безопасности ядра не ставятся автоматически по умолчанию. Пакет unattended-upgrades это исправляет, но только при правильной настройке.

Во-первых, убедитесь, что пакет установлен:

bashКопировать
sudo apt update
sudo apt install unattended-upgrades

Затем отредактируйте файл /etc/apt/apt.conf.d/50unattended-upgrades. Я обычно раскомментирую секцию с репозиторием безопасности:

textКопировать
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    "${distro_id}:${distro_codename}-updates";
};

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

textКопировать
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

Это работает на выделенных серверах и виртуалках, где простой в четыре утра допустим. Для домашнего сервера, который крутит медиасервер и Nextcloud, я предпочитаю ручную перезагрузку — чтобы не прервать запись в середине фильма. На сервере под названием Винни-Пух у меня обновления скачиваются автоматически, а перезагрузку я запускаю сам после проверки логов.

Если используется Ubuntu Pro, можно подключить Canonical Livepatch — он накладывает патчи на ядро без перезагрузки. Для критической инфраструктуры это удобное дополнение, но не полноценная замена обновлению пакетов. Перед включением автоматических перезагрузок убедитесь, что сервер подключён к источнику бесперебойного питания — иначе внезапное отключение света во время обновления может повредить файловую систему. Подробнее про настройку ИБП в Linux можно прочитать в руководстве по NUT.

Тестирование патчей перед выкаткой

Никогда не выкатывайте новое ядро сразу на все продуктивные узлы. Даже официальный патч от Canonical может сломать специфический драйвер или модуль ядра, который вы используете.

Сначала разверните стенд, максимально близкий к продакшену. У меня это отдельная нода на Proxmox, где клонируется виртуальная машина с текущей конфигурацией. На клоне устанавливаем обновленное ядро:

bashКопировать
sudo apt update
sudo apt install --only-upgrade linux-image-generic linux-headers-generic
sudo update-grub
sudo reboot

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

bashКопировать
uname -r

Затем смотрим логи на наличие ошибок загрузки модулей:

bashКопировать
journalctl -b -p err

Если всё чисто, прогоняем основные нагрузки: базу PostgreSQL, контейнеры Docker, NFS-шару. Проверяем, что сервисы стартуют, сетевые интерфейсы поднимаются, а ZFS пулы монтируются автоматически.

Следующий шаг — канареечное обновление. Я обновляю один некритичный сервер (например, Пятачок) и наблюдаю за ним сутки через Prometheus и Grafana. Если алертов нет и метрики в норме, перехожу к остальным узлам.

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

Что касается текущей ситуации с неисправленным 0day в Ubuntu — пока патча нет, я рекомендую сократить поверхность атаки: ограничить доступ к уязвимому интерфейсу через сетевой экран, проверить права на устройства в /dev, а также включить аудит системных вызовов. Как только патч появится в репозитории -security, алгоритм выше поможет доставить его на серверы без простоев и инцидентов.

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

Можно ли закрыть уязвимость без обновления ядра?

Частично. Если уязвимость проявляется через сетевой стек, можно ограничить входящий трафик на уязвимые порты через iptables или nftables, но это не защитит от локального пользователя с доступом к оболочке. С практической точки зрения, сетевой экран снижает поверхность атаки, но не устраняет ошибку в управлении памятью. Полная предсказуемость появится только после установки официального патча из репозитория Ubuntu.

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

Посмотрите версию ядра командой uname -r и сравните её с версией, в которой Canonical выпустила исправление. Если патча ещё нет в репозитории, система уязвима по умолчанию. Также стоит проверить установленные пакеты ядра через dpkg -l | grep linux-image, чтобы понять, какая версия будет обновлена при следующем apt upgrade.

Стоит ли переустановить сервер на другой дистрибутив, пока Ubuntu не выпустила патч?

Скорее нет, чем да. Переезд на другой дистрибутив ради одной уязвимости — это решение «на коленке», которое создаёт больше проблем, чем решает. Лучше применить временные ограничения на сетевом уровне и следить за обновлениями через unattended-upgrades или ручной apt update. Если у вас уже есть опыт с Debian или AlmaLinux, можно рассмотреть миграцию, но не в режиме экстренной реакции.

Безопасно ли собирать ядро вручную вместо ожидания обновления из репозитория?

Технически возможно, но для продакшена это плохая идея. Сборка ядра вручную требует отслеживания конфигурации, модулей и зависимостей, иначе вы получите систему, которую сложно поддерживать и обновлять. С точки зрения предсказуемости конфигураций, официальный пакет из репозитория Ubuntu предпочтительнее, даже если его выпуск задерживается. Если очень нужно, можно попробовать ядро из основной ветки Ubuntu (mainline), но тогда вы выходите из зоны поддержки Canonical.

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

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