Canonical перешла на еженедельные обновления ядра Ubuntu из-за ИИ-находок

Что произошло, почему это важно и что взять в работу.

Администраторам и DevOps-командам придётся перестроить регламент обслуживания: патчи ядра теперь выходят раз в неделю, а значит тесты и откат нужно автоматизировать, иначе окно уязвимости не сократится.

Связанные услуги: каталог, AI Boost Team, стать клиентом.

Неделя вместо месяца

Двадцать восемь дней на исправление ядра сжались до семи. Canonical в сентябре 2026 года объявила: ядро Ubuntu в поддерживаемых версиях будет получать обновления каждую неделю. Причина, названная официально, звучит непривычно для мира Linux — ИИ-инструменты начали находить слишком много уязвимостей, и четырёхнедельный конвейер перестал успевать за потоком отчётов. Вторая причина скромнее и прозаичнее: изменились правила учёта ошибок в самом Linux.

Механика простая, но именно она ломает привычный регламент. Каждому пакету по-прежнему дают две недели проверки: первая уходит на сборку и контроль загрузки, вторая на детальные тесты, включая совместимость с оборудованием. Раньше циклы шли последовательно, один за другим. Теперь подготовка следующего выпуска стартует, не дожидаясь финиша предыдущего. Несколько обновлений висят в работе одновременно, а на выходе получается релиз раз в неделю.

Переход растянули. Первый двухнедельный цикл стартовал 28 сентября 2026 года, второй — 12 октября, ещё в последовательном режиме. С 26 октября подготовка новых пакетов начинается каждую неделю, пока предыдущие проходят проверку.

Что было до и чего в новости нет

С августа 2023 года схема выглядела так: четырёхнедельный цикл Stable Release Updates плюс отдельный выпуск раз в две недели для срочных проблем безопасности и критичных поломок. Пакет могли пересобрать и внутри цикла, если всплывала регрессия. Так что «месяц ожидания при любых обстоятельствах» — упрощение, но общий темп был именно такой.

Новый график касается ядра в поддерживаемых версиях Ubuntu. На новую версию Linux раз в неделю никто не переходит, и это стоит помнить тем, кто читает только заголовки.

ИИ действительно находит

Скепсис понятен, но фактура есть. В ноябре 2024 года Google показала в OSS-Fuzz подход, где языковая модель пишет обвязки для фаззинга: помогает добраться до нужной функции, правильно её вызвать, собрать окружение. Результат — 26 новых уязвимостей в проектах, которые годами проверяли обычными средствами. Среди них CVE-2024-9143 в OpenSSL, которая, по оценке исследователей, могла жить незамеченной около 20 лет.

Пример из марта 2026 года: Claude Opus 4.6 за две недели нашла 22 уязвимости в Firefox, 14 из них Mozilla отнесла к высокой степени опасности. Всего ушло 112 отдельных отчётов. Каждую находку воспроизводили в изолированной виртуальной машине до передачи разработчикам, исправления вышли после подтверждения. Это картинка «как надо».

Дальше начинается та часть, которую администратору полезно знать. curl закрыл программу денежных вознаграждений 31 января 2026 года. За время её работы подтвердили 87 проблем и выплатили больше 100 тысяч долларов. Потом доля полезных обращений упала ниже 5%, и Даниэль Стенберг связывает это с потоком сгенерированных ИИ материалов и общим падением качества сообщений. Разбор одного отчёта занимал 3–4 человека, от получаса до нескольких часов у каждого. Приём сообщений не прекратили, убрали денежный стимул для «коврового бомбометания» по разработчикам.

Где ломается ваш регламент

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

Если ждать полного цикла некогда, предварительная сборка появляется в репозитории -proposed уже после первой недели подготовки. Это шанс раньше прогнать исправление на тестовом стенде со своими конфигами и приложениями. Пригодность сборки для рабочих машин придётся определять самостоятельно. Для обычного обновления системы правильнее дождаться проверенного пакета в основном репозитории.

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

Факт и что за ним

Вывод

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