Ядро Linux: отчёты о шести уязвимостях утекли до патчей — что проверить

21–22 октября команда Trend Micro Zero Day Initiative (ZDI) отправила отчёты о шести неисправленных уязвимостях ядра Linux в публичные рассылки разработчиков, а не только на закрытый адрес команды безопасности. Архивы рассылок открыты, поэтому технические детали, а для части ошибок и демонстрационный код, теперь доступны всем. 23 октября TuxCare обновила свой разбор: на нескольких популярных дистрибутивах ей удалось получить права root с помощью опубликованного кода.

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

Что оказалось в открытом доступе

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

Кого это касается

• Серверы с включённым KSMBD. Это не Samba, а отдельный SMB-сервер внутри ядра, по умолчанию он выключен. Его включают на NAS, офисных файловых серверах и самосборных хранилищах ради скорости. Если порт 445 такого сервера виден из интернета или гостевой сети, риск максимальный. В Red Hat Enterprise Linux KSMBD по умолчанию не входит, а AlmaLinux и CloudLinux 9 и 10 его не собирают.
• Общие серверы, хостинг, серверы с несколькими пользователями. Ошибка в skb_zerocopy позволяет обычному пользователю стать root. TuxCare подтвердила это на AlmaLinux 8, 9 и 10, CloudLinux 9 и 10, Debian 12 и 13, Ubuntu 24.04 и 26.04 — ограничение AppArmor в Ubuntu атаку не остановило. CentOS 6 и 7 не уязвимы, Ubuntu 22.04 и ряд других веток не проверялись. Ошибка обходит майское исправление Dirty Frag.
• Гостевые машины VMware и хранилища с NVMe-oF — только в части соответствующих отчётов.

Для сервера, на котором работает один сайт, локальная уязвимость тоже важна. Это второй шаг атаки: если злоумышленник попал на сервер через дыру в CMS или плагине, он получает шанс стать root и закрепиться так, что простая переустановка сайта уже не поможет.

Что сделать сейчас

1. Проверьте, работает ли KSMBD: systemctl is-active ksmbd и lsmod | grep ksmbd. Если сервис не нужен, отключите его (systemctl disable --now ksmbd) и выгрузите модуль.
2. Если KSMBD нужен, закройте порт 445 от интернета и недоверенных сетей на межсетевом экране, оставьте доступ только из офиса или через VPN. Не включайте SMB Direct, если в инфраструктуре нет RDMA.
3. Для ошибки skb_zerocopy TuxCare предлагает отключить непривилегированные пространства имён пользователей (user.max_user_namespaces=0). Это ломает rootless-контейнеры, Flatpak и часть песочниц браузеров, а эффективность меры в её тестах не подтверждена, поэтому сначала проверьте на тестовом сервере.
4. Более мягкий вариант — запретить загрузку модулей nlmon и act_pedit, на которые опирается опубликованный эксплойт. Полной защиты это не гарантирует.
5. Сократите круг тех, кто может запускать код на сервере: уберите лишние учётные записи и вход по SSH с паролем, закройте неиспользуемые панели управления.
6. Следите за бюллетенями своего дистрибутива и ставьте исправленное ядро сразу после выхода. Без live-патчинга после обновления ядра нужна перезагрузка — запланируйте окно заранее.

Почему так вышло и что это меняет

Обычный порядок такой: исследователь сообщает об ошибке закрыто, разработчики готовят исправление, подробности публикуют после релиза. Здесь отчёты оказались в публичных архивах раньше патчей. Сопровождающий стабильных веток ядра Грег Кроа-Хартман раскритиковал ZDI: по его словам, с одним из отчётов, присланным без исправления, «мало что можно сделать». The Hacker News отмечает, что обновлённые правила безопасности ядра допускают копию в публичные рассылки для ошибок, найденных с помощью ИИ, — а таких находок становится всё больше.

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

Источники

• Linux Kernel Vulnerabilities Hit the Public Mailing List Before the Fixes — Hardware Busters, 22.10.2026
• Two CVSS 9.0 Linux KSMBD RCE Flaws Disclosed on Public Mailing Lists — The Hacker News, 22.10.2026
• Linux Kernel skb_zerocopy Zero Day Gets Root on AlmaLinux, Debian and Ubuntu — TuxCare, обновлено 23.10.2026
• Разработчики Linux случайно раскрыли данные об уязвимостях ядра — Runet.News, 23.10.2026