CVE-2026-98536

In the Linux kernel, the following vulnerability has been resolved:

writeback: report a Tasks-RCU quiescent state per cgwb drain pass

cleanup offline cgwbs workfn() drains a dying cgwb by calling cleanup offline cgwb() until it returns false, with a cond resched() between passes. On a CONFIG PREEMPTION kernel that cond resched() does nothing: cond resched() is a plain "return 0", and under PREEMPT DYNAMIC the full and lazy modes disable it. Since commit 7dadeaa6e851 ("sched: Further restrict the preemption modes") those are the only two models on the architectures with PREEMPT LAZY support, arm64 and x86 among them, so the drain loop never reports a Tasks-RCU quiescent state.

A worker draining a cgwb with millions of attached inodes runs for minutes. On a 6.18 arm64 host in lazy mode the cgwb worker drained one dying cgroup's writeback domain for over 11 minutes. A BPF program unlink (bpf trampoline unlink prog -> bpf trampoline update -> unregister ftrace direct -> ftrace shutdown -> synchronize rcu tasks()) waited on that grace period while holding the trampoline mutex, 42 tasks queued behind it in D state, and the hung task detector fired at 614 s and panicked the host. Any BPF or ftrace detach during a long drain inherits the drain's length.

Fix this by calling cond resched tasks rcu qs() so we do not stall out anybody who calls sycnrhonize rcu tasks(). We put this in a do { } while loop because if we have many small cgroups cleanup offline cgwb() will return false and we will never call cond resched tasks rcu qs(), creating the same problem.