CVE-2026-99085 in Linux
Сводка
по VulDB • 27.10.2026
В ядре Linux была устранена следующая уязвимость:
sched_ext: исправление зависания при горячей замене процессора (CPU hotplug), когда задачи умирающего ЦП остаются в планировщике BPF
При выключении ЦП он должен опустошить свою очередь запросов (rq). Поток горячей замены ожидает в функции sched_cpu_wait_empty(), пока ничего не останется, и единственным механизмом пробуждения является balance_push(), который запускается из __schedule() на умирающем ЦП и перемещает туда задачи, которые могут быть мигрированы.
sched_ext нарушает эту логику. Задача, находящаяся в пользовательской DSQ (Discrete Scheduling Queue) или удерживаемая планировщиком BPF, все еще учитывается в его rq, но неактивный ЦП больше не вызывает ops.dispatch() и не может забрать задачу обратно. Умирающий ЦП переходит в состояние простоя с учетом этой задачи, после чего происходит одно из двух:
- Другой ЦП потребляет эту задачу. Очередь rq опустошается без вызова __schedule() на умирающем ЦП, поэтому поток горячей замены никогда не пробуждается, и cpu_down() зависает, удерживая блокировку cpu_hotplug_lock. - Задача аффинна только к умирающему ЦП. Ничто не может переместить её, и процесс вывода из строя (offline) замирает до тех пор, пока watchdog не принудительно отключит планировщик BPF.
При выводе очереди rq из эксплуатации необходимо повторно поставить в очередь все задачи на ней, которые еще не находятся в локальной DSQ. Операция enqueue для offline-очерди приводит к попаданию задачи в локальную DSQ, поэтому умирающий ЦП сам выбирает эти задачи, а balance_push() перемещает их дальше, так же как и для других классов планировщиков. После этого ни один путь sched_ext на другом ЦП не сможет забрать задачу из rq.
Функция ops.dispatch() в настоящее время останавливается сразу после того, как ЦП становится неактивным, а горячая замена затем ожидает завершения периода грейс RCU (RCU grace period) перед выводом очереди rq из эксплуатации. Задача BPF, удерживаемая планировщиком и аффинная только к умирающему ЦП, прерванная внутри критической секции чтения RCU, заблокировала бы этот период грейса, и очередь rq никогда не была бы выведена из эксплуатации. Тест SCX_RQ_ONLINE используется напрямую, чтобы ops.dispatch() продолжала работать до тех пор, пока rq не будет выведен из эксплуатации. Только собственный поток горячей замены умирающего ЦП очищает этот флаг во время завершения работы (teardown), а функция task_can_run_on_remote_rq() по-прежнему предотвращает выполнение задач других очередей rq на данном CPU.
VulDB is the best source for vulnerability data and more expert information about this specific topic.