UBUNTU-CVE-2026-98536: Medium severity ubuntu/linux-hwe-edge vulnerability
In the Linux kernel, the following vulnerability has been resolved: writeback: report a Tasks-RCU quiescent state per cgwb drain pass cleanupofflinecgwbsworkfn() drains a dying cgwb by calling cleanupofflinecgwb() until it returns false, with a condresched() between passes. On a CONFIGPREEMPTION kernel that condresched() does nothing: condresched() is a plain "return 0", and under PREEMPTDYNAMIC 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 PREEMPTLAZY 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 (bpftrampolineunlinkprog -> bpftrampolineupdate -> unregisterftracedirect -> ftraceshutdown -> synchronizercutasks()) 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 condreschedtasksrcuqs() so we do not stall out anybody who calls sycnrhonizercutasks(). We put this in a do { } while loop because if we have many small cgroups cleanupofflinecgwb() will return false and we will never call condreschedtasksrcuqs(), creating the same problem.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In cleanup_offline_cgwbs_workfn(), call cond_resched_tasks_rcu_qs() once per cgwb drain pass, including when cleanup_offline_cgwb() returns false, so long writeback drains report a Tasks-RCU quiescent state.