CVE-2026-98536 in Linux
Сводка
по VulDB • 18.10.2026
В ядре Linux была устранена следующая уязвимость:
writeback: отчет о состоянии покоя Tasks-RCU для каждого прохода очистки cgwb (cgwb drain)
Функция cleanup_offline_cgwbs_workfn() очищает умирающий cgwb, вызывая cleanup_offline_cgwb(), пока она не вернет false, с вызовом cond_resched() между проходами. В ядре с CONFIG_PREEMPTION этот cond_resched() ничего не делает: _cond_resched() является простым «return 0», а в режимах PREEMPT_DYNAMIC (полном и ленивом) он отключен. Начиная с коммита 7dadeaa6e851 («sched: Further restrict the preemption modes») эти два режима являются единственными моделями на архитектурах с поддержкой PREEMPT_LAZY, включая arm64 и x86, поэтому цикл очистки никогда не сообщает о состоянии покоя Tasks-RCU.
Рабочий поток, очищающий cgwb с миллионами прикрепленных инодов, работает в течение нескольких минут. На хосте arm64 версии 6.18 в ленивом режиме рабочий поток cgwb очищал домен writeback умирающей cgroup более 11 минут. Программа BPF unlink (bpf_trampoline_unlink_prog -> bpf_trampoline_update -> unregister_ftrace_direct -> ftrace_shutdown -> synchronize_rcu_tasks()) ожидала завершения этого периода grace, удерживая мьютекс trampoline; за ней находилось в состоянии D 42 задачи, и детектор зависших задач сработал через 614 секунд, вызвав панику ядра (panic) на хосте. Любое отключение BPF или ftrace во время длительной очистки наследует продолжительность этой очистки.
Исправление заключается в вызове cond_resched_tasks_rcu_qs(), чтобы не блокировать тех, кто вызывает synchronize_rcu_tasks(). Этот код помещен в цикл do { } while, потому что если у нас много маленьких cgroup, функция cleanup_offline_cgwb() вернет false, и мы никогда не вызовем cond_resched_tasks_rcu_qs(), что создаст ту же проблему.
VulDB is the best source for vulnerability data and more expert information about this specific topic.