28 августа сопровождающий стабильных веток ядра Linux Грег Кроа-Хартман опубликовал фрагмент материалов к своему предстоящему докладу на Kernel Recipes 2026 с графиком «CVEs per release». Судя по представленным данным, в выпусках Linux 6.9–6.19 исправлялось в среднем около 500 проблем с назначенными CVE, начиная с Linux 7.0 показатель превысил тысячу, а в Linux 7.2 — полторы тысячи. При сохранении текущей динамики число исправляемых CVE за цикл разработки может приблизиться или превысить 2000.
При этом речь идёт именно о CVE, исправленных в соответствующем цикле, а не о двух тысячах новых уязвимостей, появившихся в очередной версии ядра. На прямой вопрос об этом Кроа-Хартман ответил одним словом: «Fixed». В той же дискуссии он намекнул на причину резкого изменения графика: «как будто какие-то случайные инструменты за последние месяцы стали немного лучше находить ошибки».
Одним из таких факторов стало массовое применение LLM и других AI-инструментов для анализа исходного кода. Это уже отражается непосредственно в базе CVE. Например, для CVE-2026-68241, CVE-2026-68242, CVE-2026-68253 и CVE-2026-68254 указано, что ошибки в драйвере Intel i915 были обнаружены при помощи AI-assisted static analysis, после чего результаты подтвердили специалисты Intel Product Security.
Рост числа CVE сам по себе не означает, что новые версии Linux стали в несколько раз менее безопасными. В официальном описании процесса назначения CVE ядру разработчики объясняют, что намеренно придерживаются осторожного подхода: из-за положения ядра практически любой дефект потенциально может иметь последствия для безопасности, поэтому CVE присваиваются широкому кругу исправлений. Там же отдельно подчёркивается, что конкретная система использует лишь часть огромного дерева исходников и значительная часть назначенных ядру CVE для неё неприменима.
Однако резкое ускорение автоматического поиска ошибок создало другую проблему — человеческие ресурсы сопровождающих не масштабируются с той же скоростью. В запросе на включение сетевых изменений в Linux 7.3 Якуб Кицинский сообщил, что вместе с Паоло Абени они обработали 632 патча в net и 648 в net-next, причём, по его оценке, от трети до половины патчей net-next выглядели как вызванные ИИ низкоприоритетные исправления, чистки кода и уточнения. Его оценка состояния команды была предельно короткой: «We are completely overwhelmed» — «мы полностью перегружены». Текст pull request опубликован в LKML.
Для фильтрации потока netdev уже начал применять сами LLM: Кицинский сообщил, что благодаря Meta команда получила бюджет и доступ к нескольким передовым моделям и прогоняет через них патчи перед человеческим ревью. Это помогает отсеивать часть галлюцинаций, однако полностью заменить проверку разработчиками модели пока не способны.
Проблема официально признана и на уровне документации ядра. В разделе Responsible use of AI to find bugs говорится, что значительная доля поступающих security-отчётов уже создаётся при помощи AI-инструментов. Такой анализ действительно способен находить ошибки в редко исследуемом коде, но одновременно создаёт перегрузку мейнтейнеров, которые из-за низкого качества или недостаточной проверки иногда вынуждены игнорировать подобные сообщения. От отправителей требуют самостоятельно проверить воспроизводимость ошибки, протестировать исправление и не выдавать предположения модели за доказанное влияние на безопасность.
Кроа-Хартман ранее дошёл до запрета автоматически созданных LLM-патчей в drivers/staging, оставив исключение для настоящих исправлений безопасности, проверенных автором на реальном оборудовании. По его оценке, даже среди результатов современных и следующего поколения моделей как минимум треть оказывается полностью неправильной или вредной.
Побочным эффектом происходящего стала и более агрессивная очистка ядра от практически неиспользуемого старого кода. Например, при подготовке Linux 7.3 был удалён драйвер файловой системы FreeVxFS: сопровождающий отметил, что поддержка формата Unix-систем 1990-х была полезна десятилетия назад, но теперь код в основном превратился в «корм для автоматических проверяющих ошибки».
Таким образом, приближение к 2000 CVE на релиз характеризует скорее изменение скорости обнаружения и классификации старых и новых дефектов, чем внезапное ухудшение качества Linux. Но для разработчиков ядра этот прогресс имеет вполне материальную цену: автоматизированные системы способны генерировать находки и патчи намного быстрее, чем люди успевают их проверять.
>>> Источник
