Ядро Linux публикует 432 CVE за два дня: что это на самом деле говорит о безопасности ядра

Команда по безопасности ядра Linux опубликовала 432 CVE за 48 часов. Впечатляющая цифра, но её нужно поставить на своё место: это прямое следствие политики CNA, принятой в 2024 году.

Факты

Команда безопасности ядра Linux публикует 432 CVE за два дня — пик, который подогревает тревожные заголовки и обсуждения на списках рассылки. Цифра сама по себе неоспорима, но её интерпретация требует контекста.

С февраля 2024 года проект Linux стал CNA (CVE Numbering Authority) при MITRE. Это означает, что команда ядра может сама присваивать идентификаторы CVE своим исправлениям безопасности, не прибегая к посредникам. Прямым результатом стал взрывной рост публикаций CVE — не потому, что ядро внезапно стало менее безопасным, а потому, что каждое исправление, которое может иметь отношение к безопасности, теперь автоматически получает CVE.

Кого это касается (и как интерпретировать цифру)

В этом потоке CVE нужно различать три категории:

1. Реальные уязвимости, эксплуатируемые удалённо или с локальным повышением привилегий (LPE) — именно они требуют немедленного патча. Они остаются в меньшинстве.
2. Теоретические уязвимости в экзотических подсистемах — редко компилируемые драйверы, код архитектур с малым распространением (SH, PA-RISC, IA-64 до их вывода из эксплуатации). CVE формально корректен, но операционный риск близок к нулю для 99 % инсталляций.
3. Превентивные исправления — состояния гонки, use-after-free, которые сложно вызвать, незначительные утечки информации. Их стоит исправлять, но это не срочно.

Политика CNA ядра, отстаиваемая Грегом Кроа-Хартманом, предельно ясна: любое исправление, связанное с безопасностью, получает CVE, а пользователям (дистрибутивам, компаниям) остаётся сортировать, что их касается. Это сдвиг ответственности по сравнению с эпохой, когда CVE присваивались только уже эксплуатируемым уязвимостям — честнее с точки зрения прозрачности, но создаёт такие пики в статистике.

Новый тренд: сообщения об ошибках с помощью ИИ?

Подзаголовок статьи The Register на эту тему красноречив: пик «подпитывает спекуляции о сообщениях об ошибках, созданных с помощью ИИ». Эта идея циркулирует в списках рассылки ядра уже несколько месяцев: демократизация инструментов, которые выполняют интеллектуальный фаззинг и статический анализ с использованием LLM, генерирует поток сообщений об ошибках, и часть из них (истинные положительные срабатывания) в итоге становится исправлениями, которые, согласно политике CNA, получают статус CVE.

На данный момент официально ничего не подтверждено командой ядра. Переход к широкой модели CNA сам по себе объясняет цифры без необходимости привлекать фактор ИИ. Однако вопрос заслуживает обсуждения: если завтра значительная часть CVE будет генерироваться инструментами на базе ИИ, должен ли экосистемный подход обрабатывать такие отчёты иначе (специализированный канал, обязательная ручная проверка перед присвоением CVE, явная маркировка в описаниях)? Дискуссия ещё не завершена.

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

Анализ

Суть вопроса — давний спор в области безопасности с открытым исходным кодом: какой уровень детализации должен быть при раскрытии уязвимостей?

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

Новая модель (широкая CNA) делает реальность видимой, но непригодной для прямого использования большинством команд. Посредническую роль берут на себя дистрибутивы и системы управления патчами, а не конечный пользователь.

Честная цифра для ориентировки: ядро Linux исправляет около 1800–2500 багов в месяц в стабильных ветках. Доля, связанная с безопасностью, структурно значительна — ядро это монстр из 30+ миллионов строк C, значительная часть из которых — малоаудированный код драйверов. То, что публикация CVE отражает эту реальность, — здорово; то, что это создаёт впечатление пожара, — нет.

Кратко

• 432 CVE за 2 дня = следствие политики CNA ядра, а не краха безопасности.
• Гипотеза о «сообщениях об ошибках с помощью ИИ» циркулирует, но официально не подтверждена.
• Следуйте advisory вашего дистрибутива, а не сырому потоку ядра.