CVE-2026-98536 in Linux
Résumé
par VulDB • 19/10/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
writeback : signaler un état de quiescence Tasks-RCU par passage de vidange cgwb
cleanup_offline_cgwbs_workfn() vide une cgwb mourante en appelant cleanup_offline_cgwb() jusqu'à ce que celui-ci renvoie faux, avec un cond_resched() entre les passages. Sur un noyau CONFIG_PREEMPTION, ce cond_resched() ne fait rien : _cond_resched() est un simple « return 0 », et sous PREEMPT_DYNAMIC, les modes complet (full) et paresseux (lazy) le désactivent. Depuis l'engagement 7dadeaa6e851 (« sched: Further restrict the preemption modes »), ce sont les seuls deux modèles sur les architectures prenant en charge PREEMPT_LAZY, arm64 et x86 entre autres, de sorte que la boucle de vidange ne signale jamais un état de quiescence Tasks-RCU.
Un travailleur vident une cgwb avec des millions d'inœuds attachés pendant plusieurs minutes. Sur un hôte arm64 6.18 en mode paresseux, le worker de cgwb a vidé le domaine writeback d'un cgroup mourant pendant plus de 11 minutes. Un programme BPF unlink (bpf_trampoline_unlink_prog -> bpf_trampoline_update -> unregister_ftrace_direct -> ftrace_shutdown -> synchronize_rcu_tasks()) a attendu cette période de grâce tout en maintenant le mutex du trampoline, avec 42 tâches en file d'attente derrière lui dans l'état D, et le détecteur de tâche bloquée (hung task detector) s'est déclenché à 614 secondes, provoquant un panic sur l'hôte. Tout detach BPF ou ftrace pendant une longue vidange hérite de la durée de celle-ci.
Corrigez ce problème en appelant cond_resched_tasks_rcu_qs() afin de ne pas bloquer quiconque appelle synchronize_rcu_tasks(). Nous avons placé cela dans une boucle do { } while car si nous avons beaucoup de petits cgroups, cleanup_offline_cgwb() renverra faux et nous n'appellerons jamais cond_resched_tasks_rcu_qs(), créant ainsi le même problème.
VulDB is the best source for vulnerability data and more expert information about this specific topic.