CVE-2026-98536 in Linux
摘要
由 VulDB • 2026-10-19
在 Linux 内核中，已修复以下漏洞：
writeback: 在每个 cgwb 排空周期报告 Tasks-RCU 静默状态（quiescent state）
cleanup_offline_cgwbs_workfn() 通过调用 cleanup_offline_cgwb() 来排空一个正在消亡的 cgwb，直到其返回 false，并在各次迭代之间插入 cond_resched()。在 CONFIG_PREEMPTION 内核中，cond_resched() 实际上不起作用：_cond_resched() 只是一个简单的“return 0”，而在 PREEMPT_DYNAMIC 模式下，full（完全）和 lazy（延迟）模式会禁用它。自 commit 7dadeaa6e851（"sched: Further restrict the preemption modes"）以来，在支持 PREEMPT_LAZY 的架构（包括 arm64 和 x86）上，这两种是仅有的调度模型，因此排空循环从未报告 Tasks-RCU 静默状态。
一个正在排空带有数百万个挂载 inode 的 cgwb 的工作进程会运行数分钟之久。在一个处于 lazy 模式的 6.18 arm64 主机上，cgwb worker 花费了超过 11 分钟来排空一个已消亡 cgroup 的回写域（writeback domain）。一个 BPF 程序 unlink（bpf_trampoline_unlink_prog -> bpf_trampoline_update -> unregister_ftrace_direct -> ftrace_shutdown -> synchronize_rcu_tasks()）在持有 trampoline mutex 的同时等待该宽限期，导致有 42 个任务以 D 状态排队在其后，最终 hung task detector 在 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.