Linux cgroup: task iterator can resurrect a zero-refcount dying task, giving a use-after-free

UnscoredCVE-2026-98163Kernel, userspace & hypervisorcurated

Impact

After the dying_tasks lifetime change, a task can sit on that list between cgroup_task_release() and cgroup_task_free() with ->usage already dropped to zero and __put_task_struct_rcu_cb() imminent. The cgroup iterator released css_set_lock between css_task_iter_next() invocations and could then take a reference on such a task, returning a task_struct that is about to be freed - a use-after-free on core kernel objects. The reader side is nothing exotic: something reading cgroup.procs while a threadgroup leader and its threads exit. That is the normal behaviour of container runtimes, cgroup-aware monitoring agents and anything walking /sys/fs/cgroup on a busy node, so on a container host running many short-lived pods this is a realistic crash-or-worse path rather than a theoretical race. The fix skips ->usage==0 tasks in a new loop in css_task_iter_next(). No CVSS score is provided.

Who can reach it

Local: a reader of cgroup.procs racing with process exit. Any container or user able to read its own cgroup's process list plus churn processes can drive the window; no special privilege is described.

What to do

Update to a stable kernel carrying the ->usage==0 skip in css_task_iter_next() (two stable commits listed) and reboot the node - this is core cgroup code with no module to reload and no runtime toggle. Batch it into your next node-reboot wave across container hosts. The record names no distro fixed version.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-98163 https://git.kernel.org/stable/c/057dac23d329d5c5ed62352f2659a39fd46c6d4a https://git.kernel.org/stable/c/828938118d6c2bb711301748c3e39e4bed6a62f5

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.