← Все гайды AI Release
EN Подписаться на @ai_release1

Several Linux kernel vulnerabilities accidentally posted to public mailing list

Обновлено: 22.10.2026 · AI Release · @ai_release1
Several Linux kernel vulnerabilities accidentally posted to public mailing list

TL;DR

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

Требования и подготовка

Иллюстрация к разделу «Требования и подготовка»
Иллюстрация к разделу «Требования и подготовка»

Проверьте базу:

uname -r
cat /etc/os-release | head -n 3
df -h / | tail -n 1

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

6.x.y-<сборка-дистрибутива>
NAME="<Дистрибутив>"
VERSION="<версия>"
/dev/sda2        50G   18G   30G  38% /

Почему это работает: uname -r берёт строку версии из работающего ядра, а cat /etc/os-release — из пользовательского пространства. Если они расходятся с тем, что вы видите в трекере уязвимостей, значит вы патчите не тот хост.

Если тестовое окружение у вас на Android-терминале, порядок проверки митигаций описан в гайде по Termux и PRoot. Если ядро используется в WSL, обновление приходит вместе с обновлением Windows — см. WSL 3.0: что нового и как обновить.

Чек-лист подготовки:

Шаг 1. Инвентаризация: версия ядра и активные митигации

Что сделать: снять «слепок» хоста — версию ядра, параметры загрузки, состояние модулей и таблицу уже включённых митигаций (mitigation — обходной механизм в ядре, снижающий эксплуатируемость уязвимости без исправления кода).

Зачем: без базовой линии вы не отличите «стало лучше после патча» от «так было всегда». Митигации в /sys/devices/system/cpu/vulnerabilities/ — это интерфейс ядра, где по одному файлу на класс атак записан текущий статус.

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

sudo -v
{
  echo "host=$(hostname)"
  echo "kernel=$(uname -r)"
  echo "cmdline=$(cat /proc/cmdline)"
  grep -H . /sys/devices/system/cpu/vulnerabilities/* 2>/dev/null
  lsmod | awk 'NR>1 {print $1}'
} > kernel-inventory-$(date +%F).txt
wc -l kernel-inventory-$(date +%F).txt

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

host=web-01
kernel=6.x.y-<сборка-дистрибутива>
cmdline=BOOT_IMAGE=/vmlinuz root=/dev/sda2 ro quiet
/sys/devices/system/cpu/vulnerabilities/<имя-файла>: Mitigation: <описание>
...
128 kernel-inventory-2025-01-01.txt

Отдельно проверьте, не отключены ли митигации вручную — это частая причина «у нас всё было защищено, а после миграции нет»:

cat /proc/cmdline | tr ' ' '\n' | grep -E 'mitigations|nopti|nospectre'

Если в выводе есть mitigations=off — запишите это как отдельный риск. Почему это работает: параметры из /proc/cmdline — это фактическая командная строка текущего ядра, а не то, что записано в конфиге загрузчика.

Шаг 2. Сопоставить публично раскрытые изменения со своим железом

Иллюстрация к разделу «Шаг 2. Сопоставить публично раскрытые изменения со своим железом»
Иллюстрация к разделу «Шаг 2. Сопоставить публично раскрытые изменения со своим железом»

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

Зачем: уязвимость в ядре эксплуатируема только если соответствующий код присутствует и доступен. Драйвер несуществующего устройства или отключённый модуль — это снижение приоритета, а не «всё срочно».

Как проверить: git log показывает коммиты, а lsmod/lspci подтверждают (или опровергают) наличие подсистемы на конкретной машине.

git clone --depth 200 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git ~/linux-stable
cd ~/linux-stable
git log --oneline -n 20 --grep="CVE"

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

a1b2c3d <подсистема>: fix <краткое описание> (CVE-ГОД-НОМЕР)
...

Номера CVE (CVE — публичный идентификатор уязвимости вида CVE-ГОД-НОМЕР) и точные заголовки берите из самого коммита, не из пересказов. Если git log --grep ничего не находит, сверьтесь с документацией дерева: возможно, вы клонировали не ту ветку.

Дальше — триаж. Заполните таблицу под свой хост:

Признак в коммитеЧто проверить на хостеКоманда
Имя модуля ядраЗагружен ли модуль`lsmod \grep -i <имя-модуля>`
Сетевая подсистемаСлушает ли сервис наружу`ss -tulpn`
Файловая системаСмонтирована ли ФС`mount \grep <фс>`
Драйвер устройстваЕсть ли устройство`lspci -k \grep -i <вендор>`

Пример: коммит правит модуль nf_tables. Проверяем:

lsmod | grep -i nf_tables

Вывод с непустой строкой означает, что код на хосте активен — приоритет высокий. Пустой вывод — код не загружен, но может подгрузиться по требованию; тогда смотрите, есть ли у непривилегированных пользователей доступ к сетевому стеку (контейнеры, user namespaces).

Варианты снижения риска до выхода пакета:

# 1) Выгрузить ненужный модуль и запретить автозагрузку
sudo modprobe -r <имя-модуля>
echo "blacklist <имя-модуля>" | sudo tee /etc/modprobe.d/blacklist-<имя-модуля>.conf

# 2) Ограничить поверхность атаки через sysctl
sudo sysctl -w kernel.unprivileged_bpf_disabled=1
sudo sysctl -w kernel.kptr_restrict=2

# 3) Проверить, есть ли уже livepatch (livepatch — подмена функций ядра без перезагрузки)
ls /sys/kernel/livepatch/ 2>/dev/null && cat /sys/kernel/livepatch/*/enabled 2>/dev/null

Почему это работает: modprobe -r выгружает код из памяти, а файл в /etc/modprobe.d/ предотвращает его повторную автозагрузку. sysctl-переключатели сужают доступ непривилегированных процессов к подсистемам, которые чаще всего фигурируют в эксплойтах ядра. Настройки sysctl не постоянны — для сохранения после перезагрузки добавьте их в /etc/sysctl.d/99-hardening.conf, формат файла сверьте с документацией дистрибутива.

Шаг 3. Проверка работы и финальный результат

Иллюстрация к разделу «Шаг 3. Проверка работы и финальный результат»
Иллюстрация к разделу «Шаг 3. Проверка работы и финальный результат»

Что сделать: установить обновление (или подтвердить, что митигация активна), перезагрузиться и доказать, что изменение применилось.

Зачем: пакет в кэше и пакет в работающем ядре — разные вещи. Пока не выполнена перезагрузка, uname -r показывает старое ядро.

Как проверить: сравнить uname -r до и после, посмотреть список установленных пакетов ядра и статус митигаций.

# Debian/Ubuntu
sudo apt update && sudo apt full-upgrade -y
sudo reboot

# RHEL/Fedora
sudo dnf updateinfo list security
sudo dnf upgrade --security -y
sudo reboot

После возврата хоста:

uname -r
sudo dpkg -l 'linux-image*' 2>/dev/null | grep ^ii | tail -n 3
grep . /sys/devices/system/cpu/vulnerabilities/* | grep -v "Not affected"
lsmod | grep -i <имя-модуля>; echo "exit=$?"

Пример успешного вывода:

6.x.y-<новая-сборка-дистрибутива>
ii  linux-image-<версия>  <арх>  Linux kernel image
/sys/devices/system/cpu/vulnerabilities/<имя-файла>: Mitigation: <описание>
exit=1

Что означает успех: строка uname -r отличается от значения в файле инвентаризации из Шага 1; в списке пакетов есть новый linux-image-<версия>; в выводе митигаций нет строки Vulnerable; lsmod не содержит проблемный модуль (exit=1 — это нормальный результат, grep не нашёл совпадений).

Возможные проблемы и решения

Проблема. Обновление ядра не устанавливается, apt пишет про удержанные пакеты

Проблема. Модуль не выгружается, митигация не применяется

Проблема. Файл митигации отсутствует

Резюме и следующие шаги

Вы получили воспроизводимый цикл: инвентаризация → сопоставление публично раскрытых коммитов со своим железом → митигация и проверка после перезагрузки. Дальше автоматизируйте Шаг 1 в cron или в системе управления конфигурациями, чтобы сравнивать слепки между хостами и замечать отключённые митигации до инцидента.

FAQ

Почему утечка в рассылку опаснее обычного CVE?

Детали патча видны публично до выхода пакета, поэтому окно между «все знают» и «все обновились» больше. Отсюда приоритет на митигации из Шага 2.

Можно ли обойтись без перезагрузки?

Да, если для вашего ядра доступен livepatch: проверка — ls /sys/kernel/livepatch/ и cat /sys/kernel/livepatch/*/enabled. Наличие и состав пакетов livepatch для вашего дистрибутива сверьте с документацией.

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

Сверьте загруженные модули (lsmod) и открытые порты (ss -tulpn) с подсистемой из коммита. Нет кода в памяти — нет эксплуатации этим путём, но остаётся автозагрузка модуля по требованию.

Что делать, если патча ещё нет, а сервис критичный?

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

🤖 Кратко для ИИ

📚 Связанные гайды

Как запустить Linux на Android без root: Termux, PRoot и ИИ-инструменты

Пошаговое руководство по запуску полноценного Linux на Android-смартфоне без root-прав с помощью Termux и PRoot, включая

WSL 3.0: что нового и как обновить Linux-подсистему в Windows

Разбираем нововведения WSL 3.0, системные требования и пошаговое обновление подсистемы Linux в Windows 11.