CVE-2026-98536 in Linux
Sumário
de VulDB • 18/10/2026
No kernel Linux, a seguinte vulnerabilidade foi resolvida:
writeback: relatar um estado de quiescência Tasks-RCU por passagem de drenagem cgwb
A função `cleanup_offline_cgwbs_workfn()` drena uma `cgwb` moribunda chamando `cleanup_offline_cgwb()` até que esta retorne falso, com uma chamada a `cond_resched()` entre as passagens. Em um kernel configurado com CONFIG_PREEMPTION, essa chamada a `cond_resched()` não faz nada: `_cond_resched()` é apenas um "return 0", e sob PREEMPT_DYNAMIC os modos full (completo) e lazy (preguiçoso) desativam-na. Desde o commit 7dadeaa6e851 ("sched: Further restrict the preemption modes"), esses são os únicos dois modelos nas arquiteturas com suporte a PREEMPT_LAZY, incluindo arm64 e x86; portanto, o loop de drenagem nunca relata um estado de quiescência Tasks-RCU.
Um worker que drena uma `cgwb` com milhões de inodes anexados executa por minutos. Em um host arm64 6.18 no modo lazy, o worker da `cgwb` drenou o domínio de writeback de um cgroup moribundo por mais de 11 minutos. Um programa BPF unlink (bpf_trampoline_unlink_prog -> bpf_trampoline_update -> unregister_ftrace_direct -> ftrace_shutdown -> synchronize_rcu_tasks()) aguardou esse período de grace period enquanto mantinha o mutex do trampoline, com 42 tarefas enfileiradas atrás dele no estado D, e o detector de hung task disparou aos 614 segundos, causando panic (falha crítica) no host. Qualquer desanexo BPF ou ftrace durante uma drenagem longa herda a duração da drenagem.
Corriga isso chamando `cond_resched_tasks_rcu_qs()` para não bloquear ninguém que chame `sycnrhonize_rcu_tasks()`. Colocamos isso em um loop do { } while porque, se houver muitos cgroups pequenos, `cleanup_offline_cgwb()` retornará falso e nunca chamaremos `cond_resched_tasks_rcu_qs()`, criando o mesmo problema.
If you want to get best quality of vulnerability data, you may have to visit VulDB.