Linux Kernel 7.3.1, опубликованный 30 октября 2026 года, устраняет способ вычисления адресов ядра через подсистему ключей — такая утечка ослабляла защитный механизм KASLR. В обновлении также исправлены случаи незаметного усечения дампов памяти, ошибки асинхронного ввода-вывода io_uring и проблемы трассировки, которые затрагивали безопасность и диагностику Linux.
Через keyring можно было определить расположение ядра в памяти
Подсистема ключей Linux (keyring) хранила элементы в порядке, который частично зависел от адресов внутренних структур ядра. При чтении содержимого связки ключей через KEYCTL_READ пользователь получал их идентификаторы в этом порядке. Автор исправления показал, что непривилегированный процесс мог добавлять ключи с заранее известными описаниями, анализировать последовательность и вычислять адрес, по которому загружен образ ядра.
В описании патча приведён конкретный ориентир: для сборки x86-64 с выравниванием 16 МиБ хватало 45 пользовательских ключей, чтобы различить возможные варианты смещения KASLR. Эта технология случайным образом размещает ядро в памяти и затрудняет использование других уязвимостей. Утечка ослабляла KASLR и могла облегчить использование других уязвимостей. Сама по себе она не предоставляет процессу дополнительных привилегий.
В Linux 7.3.1 индексы keyring больше не зависят от адресов указателей. Вместо них используются отдельные идентификаторы типов и доменов ключей, а для вычисления хеша — SipHash со случайным секретным ключом. Формат данных, который видят программы, и проверки прав доступа при этом не изменились.
В ту же группу исправлений вошла ошибка обработки ограничений доверия: определённые операции с ключом PKCS#8 без идентификаторов могли вызвать обращение к нулевому указателю и аварийное завершение ядра. Патч отклоняет такой ключ при использовании в качестве доверенного основания. Исправлены и несколько гонок при обращении к связкам ключей, включая чтение уже освобождённой памяти.
Дампы памяти после аварийного завершения могли оказаться неполными
Дамп памяти (coredump) сохраняет состояние программы в момент сбоя. По нему разработчики находят причину падения: смотрят стеки вызовов, содержимое памяти и данные потоков. До этого релиза такая запись иногда прерывалась внутренним уведомлением TIF_NOTIFY_SIGNAL, в том числе связанным с io_uring.
Проблема проявлялась при передаче дампа через канал (pipe) или сокет сервису сбора ошибок. Когда буфер заполнялся, операция записи могла прерваться, а дамп — обрезаться. При этом признаки успешного завершения, доступные пользовательским программам, сохранялись. В результате система диагностики могла получить неполный снимок без явного предупреждения.
В Linux 7.3.1 скорректировали обработку уведомлений и сигналов во время создания дампа. Внутреннее TIF_NOTIFY_SIGNAL больше не должно обрывать такую запись; отдельно согласована реакция на SIGKILL и замораживание процессов через механизмы управления питанием и cgroup. Правки затрагивают и завершение потоков, чтобы их состояние не приводило к преждевременному прекращению записи.
С этим же набором изменений связано исправление ожидания завершения процессов в пространстве имён PID. Раньше повторяющееся уведомление могло мешать служебному процессу reaper заснуть и приводить к активному циклу ожидания. Такая механика встречается в окружениях с изоляцией процессов, включая контейнеры.
io_uring получил исправления зависающих запросов и задержек таймеров
io_uring — интерфейс Linux для асинхронных операций ввода-вывода. Его используют программы, которым нужно выполнять множество операций с файлами или сетью и получать результаты через общую очередь завершений.
Одна из исправленных ошибок касалась запросов с механизмом drain, который задаёт порядок выполнения операций. Даже после появления сообщения о завершении запроса следующие операции могли оставаться отложенными до освобождения внутренней ссылки рабочего потока. Теперь состояние drain завершается своевременно, когда соответствующий запрос закончил работу и очередь отложенных операций пуста.
Другая правка касается IORING_OP_WAITID: при многократных неудачных попытках отмены запроса мог переполниться 31-битный счётчик ссылок. Это создавало возможность повторного завершения одной операции. Исправление делает повторные попытки отмены безопасными для этого счётчика. Разработчики также устранили зацикливание обработчика опроса при событии закрытия соединения (HUP) и некорректный расчёт длины сетевого буфера размером от 2 ГиБ.
Отдельно исправили пробуждение задач реального времени по таймеру ожидания io_uring. В проверке на Jetson Orin Nano с ядром 6.18.39-rt, куда перенесли тот же патч, из 40 000 ожиданий 6 647 завершались с опозданием более 100 микросекунд. После исправления таких опозданий не зафиксировали, максимальное составило 18 микросекунд. Это результат конкретного теста с перенесённым исправлением, а не универсальный показатель производительности Linux 7.3.1.
Трассировка и Bluetooth получили защиту от ошибок обработки состояния
В фильтрах событий трассировки обнаружили ошибку разбора незаконченных логических выражений. Например, строка, обрывающаяся после &&, могла привести к чтению за границей внутреннего массива. Такой путь был достижим через PERF_EVENT_IOC_SET_FILTER для определённого события perf. Теперь неполные выражения отклоняются до этапа, на котором возникало ошибочное обращение к памяти.
В Bluetooth исправили гонку в протоколе L2CAP: при определённой последовательности операций подключения и привязки один канал мог повторно присоединиться к соединению. Новые проверки состояния предотвращают такое дублирование.
Есть и исправление, заметное при анализе больших серверов. На системах со 192 или 384 логическими процессорами файл /proc/interrupts иногда терял строку заголовка с названиями CPU при повторной генерации содержимого. Теперь заголовок воспроизводится корректно, в том числе когда вывод не помещается во внутренний буфер с первого раза.
Linux 7.3.1 стал первым стабильным исправлением ветки 7.3
Основная версия Linux 7.3 появилась 18 октября 2026 года, а 30 октября проект опубликовал 7.3.1 со статусом stable. Так устроен цикл сопровождения ядра: после основного выпуска в поддерживаемую ветку переносят проверенные исправления конкретных ошибок.
Выпуск на kernel.org и появление пакета в Ubuntu, Debian, Fedora или другом дистрибутиве происходят по разным графикам. Разработчики дистрибутивов сопровождают собственные сборки и могут переносить исправления без перехода на тот же номер версии.
У первого корректирующего выпуска 7.3 есть несколько самостоятельных последствий: изменён способ формирования индексов ключей, устранены случаи потери диагностических данных и исправлены конкретные состояния гонки в io_uring, трассировке и Bluetooth. Насколько заметными окажутся эти изменения на отдельной системе, зависит от используемых механизмов ядра и того, какие из исправлений уже включены в её сборку.
