CVE-2026-98536

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

Published Oct 18, 2026 CVSS 3.1 · 4.7 Medium EPSS < 1% KEV · Not listed
Description
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.

Remediation

No solution or workaround provided in the CVE record

Tracking

Sign in to view the affected projects.

Advisories

Source ID Title
Debian DLA Debian DLA DLA-4850-1 linux-6.12 security update
Ubuntu USN Ubuntu USN USN-8961-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-9019-1 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-9020-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-9022-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-9023-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-9024-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-9025-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-9026-1 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-9029-1 Linux kernel (Raspberry Pi) vulnerabilities
Ubuntu USN Ubuntu USN USN-9039-1 Linux kernel (Azure CVM) vulnerabilities
Ubuntu USN Ubuntu USN USN-9040-1 Linux kernel (Low Latency NVIDIA) vulnerabilities
Ubuntu USN Ubuntu USN USN-9066-1 Linux kernel (HWE) vulnerabilities
Ubuntu USN Ubuntu USN USN-9091-1 Linux kernel (NVIDIA Tegra) vulnerabilities
History
Type Values Removed Values Added
Weaknesses CWE-106
Type Values Removed Values Added
Weaknesses CWE-821
References
Metrics threat_severity

None

cvssV3_1

{'score': 4.7, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Moderate

Type Values Removed Values Added
Weaknesses CWE-106
Type Values Removed Values Added
Description 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.
Title writeback: report a Tasks-RCU quiescent state per cgwb drain pass
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References
Weaknesses

Sources

Status
PUBLISHED
Assigner
Linux
Published
Updated
Oct 19, 2026, 9:21 AM
Reserved
Sep 25, 2026, 10:25 AM
Status
Received
Published
Oct 18, 2026, 4:17 PM
Modified
Oct 19, 2026, 10:19 AM
Severity
Moderate
Public date
Oct 18, 2026, 12:00 AM