Мейнтейнеры Linux 30 июля 2026 года одновременно выпустили версии 6.18.41, 6.12.100, 6.6.147, 6.1.180, 5.15.213 и 5.10.262. Все шесть обновлений закрывают CVE-2026-64560 — гонку в POSIX CPU timers, при которой ядро могло обратиться к уже освобождённой памяти.
Один дефект обновил все поддерживаемые LTS-ветки Linux
Обычно одновременный выпуск шести ядер выглядит как крупная серия исправлений для драйверов, файловых систем и сетевого стека. На этот раз картина другая: 30 июля на kernel.org появились шесть компактных LTS-релизов, объединённых одной уязвимостью в подсистеме процессорных таймеров.
| LTS-ветка | Новая версия | Плановый срок поддержки |
| Linux 6.18 | 6.18.41 | декабрь 2028 года |
| Linux 6.12 | 6.12.100 | декабрь 2028 года |
| Linux 6.6 | 6.6.147 | декабрь 2027 года |
| Linux 6.1 | 6.1.180 | декабрь 2027 года |
| Linux 5.15 | 5.15.213 | декабрь 2026 года |
| Linux 5.10 | 5.10.262 | декабрь 2026 года |
Во всех ветках появился патч posix-cpu-timers: Prevent UAF caused by non-leader exec() race. В Linux 6.18.41 к нему добавлено подготовительное изменение интерфейса таймеров, которое само по себе не меняет поведение ядра. Остальные пять релизов фактически сосредоточены на одном исправлении.
Такой синхронный выпуск показывает масштаб охвата ошибки. Уязвимый код присутствовал в Linux начиная с версии 5.7, поэтому патч понадобился каждому LTS-ядру, которое сейчас поддерживает сообщество.
Гонка потоков оставляла таймер со ссылкой на освобождённую память
POSIX CPU timers отсчитывают процессорное время, использованное процессом или потоком. Их применяют профилировщики, средства контроля ресурсов и программы, которым нужно реагировать после достижения заданного объёма вычислений.
CVE-2026-64560 возникает при редком совпадении двух операций. Один поток удаляет процессорный таймер, пока другой поток той же группы выполняет exec() и становится новым лидером процесса. Ядро в этот момент может получить устаревшие сведения о прежнем лидере и завершить удаление таймера некорректно.
Объект таймера освобождается, хотя его узел остаётся в очереди. Следующая операция с таймерами обращается к памяти, которую система уже считает свободной. Такой класс ошибок называют use-after-free, или UAF. Он способен вызвать сбой ядра, повреждение данных в памяти и другие непредсказуемые последствия.
В официальном уведомлении о CVE-2026-64560 описан ещё один эффект: повторная постановка таймера иногда не срабатывала, после чего он переставал выдавать события. Для сервисов, использующих процессорные лимиты или точный учёт времени выполнения, это создаёт риск скрытого нарушения логики без немедленного падения системы.
Публичное уведомление Linux Kernel CVE Team пока не приводит оценку CVSS и не описывает готовый сценарий эксплуатации. Подтверждённый факт ограничивается самой гонкой, возможностью UAF и ошибочным поведением таймеров. Поэтому при оценке риска лучше опираться на наличие уязвимого ядра и доступность обновления, сохраняя осторожность с заявлениями о практической атаке.
Ошибка появилась в Linux 5.7 и дошла до шести поколений LTS
Текущая уязвимость связана с изменением, добавленным в Linux 5.7. Тогда таймеры начали хранить ссылку на идентификатор процесса; прежняя реализация обращалась напрямую к структуре задачи. Решение устранило прежнюю проблему, связанную со сменой лидера группы потоков, но оставило узкое окно гонки между удалением таймера и exec().
История этого участка кода тянется ещё с 2010 года, когда разработчики добавили временный обходной механизм для многопоточного exec(). Он просуществовал около десяти лет, после чего архитектуру изменили. Новая реализация оказалась устойчивее в обычных сценариях, хотя редкое сочетание операций осталось необработанным.
Исправление меняет порядок публикации данных между ядрами процессора и заставляет код повторно искать актуальную задачу, когда прежний лидер уже исчез. Здесь особенно важна синхронизация памяти: один процессор должен увидеть все изменения, выполненные другим, прежде чем продолжит работу с таймером.
Патч попал в основную ветку Linux 7.2 на стадии 7.2-rc3, а в стабильной серии 7.1 исправление присутствует с версии 7.1.5. Выпуски от 30 июля перенесли ту же коррекцию в поддерживаемые LTS-ветки, включая Linux 5.10, вышедший в 2020 году.
Дистрибутивы доставят исправление под собственными номерами пакетов
Большинство пользователей не устанавливают ядра напрямую с kernel.org. Ubuntu, Debian, Fedora, SUSE, Red Hat и другие дистрибутивы собирают собственные пакеты, добавляют патчи и используют отдельную нумерацию. Поэтому исправленное ядро в репозитории может сохранять прежнюю базовую ветку и отличаться суффиксом сборки.
Проверить запущенную версию можно командой:
uname -rНаличие 5.10, 5.15, 6.1, 6.6, 6.12 или 6.18 в выводе ещё не доказывает уязвимость. Производитель дистрибутива мог перенести патч без смены базового номера. Надёжный ориентир — бюллетень безопасности и changelog конкретного пакета ядра.
После установки нового пакета системе обычно требуется перезагрузка, поскольку прежнее ядро продолжает работать в памяти до следующего запуска. На серверах стоит проверить фактически загруженную версию командой uname -r уже после перезагрузки. Средства live patching могут закрыть отдельные уязвимости без остановки, но доступность такого патча зависит от поставщика и тарифа поддержки.
Администраторам самосборных ядер проще сверяться с номерами upstream-релизов: исправление включено в 6.18.41, 6.12.100, 6.6.147, 6.1.180, 5.15.213 и 5.10.262, а также во все последующие версии этих веток.
Компактный релиз закрывает проблему на серверах, ПК и встраиваемых системах
Масштаб обновления виден по охвату: одна и та же коррекция понадобилась всем поддерживаемым LTS-веткам. Одна гонка затронула шесть поколений LTS-ядер, которые используются в облачных серверах, корпоративных дистрибутивах, сетевом оборудовании, промышленных устройствах и домашних компьютерах.
Особого внимания требуют системы на Linux 5.10 и 5.15: для обеих веток kernel.org сейчас указывает окончание поддержки в декабре 2026 года. Патч CVE-2026-64560 для них уже выпущен, но владельцам долго живущего оборудования вскоре понадобится решение поставщика о переходе на более новую базовую ветку или продлённом сопровождении.
После выпуска 30 июля нужно дождаться обновлённого пакета дистрибутива, установить его стандартным способом и проверить, что система загрузилась с новым ядром. Синхронное обновление шести веток подтверждает, что исправление приоритетно для поддерживаемых Linux-систем.
