Девятого октября 2026 года Canonical опубликовала бюллетень USN-8911-1: для Ubuntu 24.04 LTS вышла новая сборка ядра ветки linux-oem-6.17 с номером 6.17.0-1033.33. Бюллетень ссылается на 29 идентификаторов CVE и перечисляет 17 подсистем, от сетевого стека до USB. Поставить такое обновление умеет каждый. Настоящая работа начинается потом: apt отчитался без ошибок, в списке пакетов красуется свежее ядро, и всё выглядит законченным. Но процессор по-прежнему исполняет то старое ядро, которое загрузилось неделю или месяц назад.
В этом и кроется главная ловушка. Исправленный код уже лежит на диске в каталоге /boot, а защищает систему только то ядро, что загружено в память. Если же на машине стоят сторонние модули, картина усложняется: из-за смены ABI Canonical прямо требует пересобрать и переустановить их. Ниже разобрано, чем "пакет установлен" отличается от "исправленное ядро работает" и что проверять на каждом шаге.
Бюллетень от 9 октября закрывает 29 записей CVE в сетевых, файловых и USB подсистемах ядра
Бюллетень относится к пакету linux-oem-6.17, то есть к ядру для OEM-систем на Ubuntu 24.04 LTS. Формулировка у Canonical сдержанная: найдено несколько проблем безопасности, и злоумышленник теоретически способен использовать их, чтобы скомпрометировать систему. Подробностей о приёмах нет, зато есть список из 17 подсистем.
Список удобно разделить на три группы. Первая сетевая: IPv4, IPv6, Netfilter, Open vSwitch, SCTP, TIPC, сокеты RxRPC, протокол B.A.T.M.A.N. и сетевые драйверы. Вторая файловая: клиент SMB, а также GFS2, OCFS2 и библиотека Ceph. Третья относится к оборудованию: ядро USB, аппаратные криптографические драйверы, звуковые драйверы SoundWire (SDCA) и драйвер контроллера памяти NVIDIA Tegra.
Для обычного ноутбука вес этих групп разный. Стек IPv4 и IPv6, Netfilter, USB и SMB работают на большинстве машин, тогда как GFS2 и OCFS2 нужны кластерам с общим диском, а Tegra встречается в специфической технике. Но ядро ставится целиком, и исправления приходят пачкой: выбрать один патч из сорока нельзя. Отдельно про SoundWire: по этой шине в современных ноутбуках подключаются аудиокодеки, а OEM-ядро как раз и делается под свежее железо производителей.
Темп у ветки заметный. Сборка 6.17.0-1028.28 вышла 1 июля 2026 года, 6.17.0-1030.30 последовала 23 июля, а 6.17.0-1033.33 пришла 9 октября. Номера идут с пропусками, и каждая сборка просит перезагрузки. Значит, вопрос "когда и как перезагружать OEM-машину" возникает у владельца такой ветки не раз в год, а несколько раз за квартал.
Семейство метапакетов OEM для Ubuntu 24.04 само подтягивает новую сборку, но ядро в памяти остаётся прежним
В таблице пакетов бюллетеня семь строк. Первая: linux-image-6.17.0-1033-oem, конкретный образ ядра с точной версией в названии. Остальные шесть: linux-image-oem-24.04, linux-image-oem-24.04a, linux-image-oem-24.04b, linux-image-oem-24.04c, linux-image-oem-24.04d и linux-image-oem-6.17. Это метапакеты. Своего кода в них почти нет, зато у них важная работа: они зависят от самой свежей версионной сборки и тянут её при обновлении. Во всех семи строках стоит одна версия 6.17.0-1033.33, поэтому любой из вариантов приводит к одному и тому же ядру.
Именно метапакеты создают иллюзию завершённости. apt обновляет их, кладёт новый образ рядом со старым, перестраивает меню загрузчика, и в списке пакетов появляется 6.17.0-1033.33. Старый образ не исчезает: в /boot лежат оба, и до перезагрузки работает прежний. Особенность двоякая. С одной стороны, при проблеме с новой сборкой есть куда откатиться. С другой, обновление вроде бы выполнено, а защита ещё не включена.
Разницу показывают четыре команды:
dpkg -l 'linux-image-*oem*' | grep '^ii'
apt-cache policy linux-image-oem-24.04
uname -r
cat /proc/version_signature
Первая выводит все установленные образы OEM, вторая показывает строки Installed и Candidate для метапакета. Третья говорит, какое ядро работает прямо сейчас, и тут есть нюанс: uname -r отдаёт 6.17.0-1033-oem без хвоста ".33". Полную версию Ubuntu, с номером сборки через точку, содержит четвёртая команда.
Бывает и так, что установлена новая сборка, перезагрузка была, а uname -r всё равно показывает старую. Первым подозреваемым стоит сделать загрузчик. Если в системе помимо OEM стоит другая ветка ядра, например обычная generic, меню GRUB упорядочивает записи по версии, а не по имени ветки. Параметр GRUB_DEFAULT в файле /etc/default/grub со значением 0 берёт первую запись меню, а значение saved берёт ту, что сохранилась при прошлом выборе. Запись, закреплённая вручную полгода назад, нередко и объясняет, почему машина упорно грузится в прежнюю сборку.
Изменение ABI делает старые сторонние модули непригодными для новой сборки и требует их пересборки
Canonical добавила в бюллетень отдельное предупреждение. Из-за неизбежной смены ABI обновлению присвоен новый номер версии, и все сторонние модули ядра придётся пересобрать и переустановить. Для самого ядра дополнительных действий не нужно: если стандартные метапакеты не удалялись вручную, переход на новую версию произойдёт при обычном обновлении системы. А вот чужой код остаётся на совести администратора.
Что такое ABI на практике? Это бинарный вид внутренних структур и функций ядра. Модуль, собранный под одну версию, хранит в себе строку vermagic и контрольные суммы использованных символов (modversions). При загрузке ядро сверяет их, и несовпадение заканчивается отказом. Команда modprobe сообщает "Exec format error", а журнал ядра жалуется, что модуль "disagrees about version of symbol", обычно на символ module_layout. Сверить версию можно заранее:
modinfo -F vermagic v4l2loopback
Если в ответе стоит 6.17.0-1030-oem, а запускаться предстоит 6.17.0-1033-oem, модуль под новое ядро ещё не собран.
Свои модули Canonical пересобирает сама. В составе сборки 1028 той же ветки видны отдельные пакеты модулей evdi, ipu6, ipu7, iwlwifi, usbio и vision, и в имени каждого стоит версия ядра. Эта работа выполнена заранее и приходит вместе с обновлением. Беспокоиться стоит о том, что ставилось из других мест: проприетарные драйверы видеокарт, VirtualBox, v4l2loopback, драйверы Wi-Fi Broadcom, модули, собранные вручную из исходников.
Тут стоит различать два вида драйверов NVIDIA. Одни приходят как предсобранные подписанные модули под конкретную версию ядра, их обновляет сам репозиторий, и они появляются в системе вместе с новой сборкой или чуть позже. Другие ставятся как DKMS-пакеты и собираются на машине. От вида зависит поведение после обновления, поэтому команда dpkg -l с поиском по имени драйвера выясняет это за секунды.
Состояние DKMS и журнал сборки показывают, дошёл ли внешний модуль до новой версии ядра
DKMS (Dynamic Kernel Module Support) хранит исходники модулей в каталоге /usr/src и пересобирает их под каждое новое ядро. Запускает сборку хук /etc/kernel/postinst.d/dkms, который срабатывает при установке образа. Условие одно: на машине должны быть заголовки linux-headers той же версии, иначе собирать не из чего. Состояние покажет команда:
dkms status
В выводе должны быть строки вида "v4l2loopback/0.13.2, 6.17.0-1033-oem, x86_64: installed" для каждой пары "модуль плюс ядро". Это только пример формата: у конкретной машины будут свои модули и свои версии. Статус installed означает готовность. Статусы added и built говорят, что дело не доведено до конца, а полное отсутствие строки для новой версии означает, что сборка не запускалась или упала.
Падает она чаще всего по трём причинам: нет заголовков, исходники модуля не рассчитаны на новую версию ядра или компилятор отказался собирать код. Подробности лежат в журнале: /var/lib/dkms/имя/версия/build/make.log. Сообщение об ошибке легко потерять среди сотен строк вывода apt, а иногда оно выглядит как обычное предупреждение, и обновление формально завершается успешно.
Если модуль не собрался, пересобрать его можно до перезагрузки, ядро для этого запускать не требуется:
sudo apt install linux-headers-6.17.0-1033-oem
sudo dkms autoinstall -k 6.17.0-1033-oem
Первая строка добавляет заголовки на случай, если их нет, вторая собирает и ставит все зарегистрированные модули под нужную версию. Для одного модуля подойдёт форма sudo dkms install имя/версия -k 6.17.0-1033-oem. После неё стоит повторить dkms status.
Secure Boot отвергает неподписанные модули, поэтому подпись ключом MOK нужно проверить до перезагрузки
Успешная сборка ещё не гарантирует загрузку модуля. На машинах с включённым Secure Boot ядро работает в режиме блокировки и принимает только подписанные модули. DKMS в Ubuntu подписывает собранный модуль ключом MOK, пара которого лежит в каталоге /var/lib/shim-signed/mok/. Публичную часть нужно внести в список доверенных ключей прошивки. Обычно это делается при первой установке драйвера: система предлагает придумать пароль, а при следующей загрузке запрашивает его на синем экране MokManager.
Проверка занимает минуту:
mokutil --sb-state
cat /sys/kernel/security/lockdown
mokutil --test-key /var/lib/shim-signed/mok/MOK.der
modinfo -F signer v4l2loopback
Первая команда сообщает, включён ли Secure Boot. Вторая показывает режим блокировки: значение в квадратных скобках, например [integrity], означает активный режим. Третья отвечает, внесён ли ключ в список доверенных. Четвёртая выводит подписанта модуля: пустая строка при включённом Secure Boot тревожный признак.
Когда ключ не внесён, итог выглядит однообразно. modprobe выдаёт "Key was rejected by service", а в журнале ядра появляется строка "Lockdown", где сказано, что загрузка неподписанных модулей ограничена. Типичное следствие: после перезагрузки пропадает драйвер видеокарты и рабочий стол переходит на запасной вариант, либо исчезает сеть, если Wi-Fi держится на внешнем модуле.
Страховка есть. Предыдущая сборка обычно остаётся в разделе Advanced options for Ubuntu меню GRUB, и через неё можно вернуть работоспособную систему. Но слово "обычно" лучше заменить проверкой: команда ls /boot/vmlinuz* покажет, какие образы на самом деле лежат на диске. Автоматическая чистка пакетов способна убрать старое ядро в самый неудобный момент.
Таблица сверки отделяет установленный пакет от исправленного ядра, которое действительно работает
У каждой проверки из этой статьи есть пара: что должно получиться и что говорит о проблеме. Сведённые вместе, они образуют таблицу, где отдельно видны диск и память, то есть "пакет установлен" и "исправленное ядро работает".
| Что проверяется | Команда | Признак порядка | Признак проблемы | | Какая сборка установлена | dpkg -l linux-image-oem-24.04 | версия 6.17.0-1033.33 | прежняя версия, обновление не применилось | | Какое ядро работает | uname -r | 6.17.0-1033-oem | меньший номер сборки, перезагрузки не было | | Ждёт ли система перезагрузки | ls /var/run/reboot-required | файла нет | файл есть, в нём пакеты с запросом | | Что говорит needrestart | sudo needrestart -k -b | NEEDRESTART-KSTA: 1 | значения 2 или 3 | | Собран ли модуль DKMS | dkms status | installed для 6.17.0-1033-oem | нет строки или статус added | | Подходит ли модуль ядру | modinfo -F vermagic имя | 6.17.0-1033-oem | прежний номер сборки | | Загружен ли модуль | lsmod, затем поиск имени | модуль в списке | пустой вывод | | Подписан ли модуль | modinfo -F signer имя | непустой подписант | пусто при включённом Secure Boot |
Читать таблицу удобно сверху вниз. Первые две строки решают главный вопрос: если номер сборки в dpkg и в uname -r расходится, защита от исправленных уязвимостей не включена, как бы ни выглядел список пакетов. Третья строка даёт быстрый сигнал: файл /var/run/reboot-required создаёт хук обновлений, а соседний файл reboot-required.pkgs перечисляет пакеты, которые попросили перезагрузку. На минимальных установках этого хука может не быть, поэтому полагаться только на файл нельзя.
Четвёртая строка надёжнее. В пакетном режиме needrestart печатает несколько строк, среди которых текущее ядро (NEEDRESTART-KCUR), ожидаемое (NEEDRESTART-KEXP) и состояние (NEEDRESTART-KSTA). Единица значит, что работает актуальное ядро. Двойка говорит об ожидающем обновлении, совместимом по ABI, тройка об ожидающей смене версии, и в случае этого бюллетеня именно тройка станет обычным результатом до перезагрузки.
Короткий порядок действий после бюллетеня помогает не пропустить ни одну из проверок
Из таблицы получается рабочая последовательность. Её удобно держать под рукой для любой следующей сборки OEM-ядра, потому что схема не меняется от номера к номеру:
- Обновить пакеты командой sudo apt update и sudo apt full-upgrade, дождавшись завершения хуков DKMS и просмотрев вывод на предмет ошибок сборки;
- Выполнить dkms status и убедиться, что для 6.17.0-1033-oem у каждого внешнего модуля стоит статус installed;
- Проверить Secure Boot и подпись: ключ MOK внесён, modinfo показывает подписанта;
- Перезагрузить машину в заранее выбранное окно, не откладывая до удобного случая;
- Выполнить uname -r и needrestart -k, убедившись, что работает ядро 6.17.0-1033-oem;
- Проверить lsmod на наличие нужных модулей и просмотреть журнал ядра на предмет отказов загрузки.
Автоматические обновления закрывают проблему лишь наполовину. Служба unattended-upgrades умеет ставить обновления безопасности сама, но перезагрузку выполняет только по явной настройке. В файле /etc/apt/apt.conf.d/50unattended-upgrades за это отвечают два параметра:
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:30";
Для сервера без внешних модулей такая схема удобна: ядро обновляется и подхватывается без участия человека. Для ноутбука с DKMS-драйверами она рискованна. Если модуль не собрался или не подписан, машина ночью перезагрузится и утром встретит хозяина урезанной системой без сети или графики. Разумнее оставить установку автоматической, а перезагрузку делать руками после проверки подписи и статуса DKMS.
Обновление ядра заканчивается не тогда, когда apt печатает последнюю строку, а тогда, когда uname -r показывает новый номер сборки, а нужные модули стоят на своих местах. Всё, что между этими двумя моментами, и составляет работу администратора OEM-системы.