CVE-2026-98163

High · 7.8

CVSS

7.8

EPSS

0.1%

Published

Sep 26, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in the Linux kernel's handling of process groups can let a local user cause the system to crash or potentially gain higher privileges.

Exploitation: Local Privilege
Attacker needs: Low Privilege
Complexity: Moderate
Impact: Full Compromise
Component: OS kernel
Class: Race Condition
Remediation: Patch
Effort: Medium
Patch risk: Medium

What it actually does

Race condition in cgroup task iteration allows css_task_iter_next to obtain a reference on a task_struct whose usage count has already reached zero after cgroup_task_release but before cgroup_task_free, resulting in use-after-free when the iterator later dereferences the freed object.

Why it matters to the business

Local users on affected Linux systems can trigger kernel memory corruption, leading to crashes, denial of service, or potential elevation of privileges; the issue affects all distributions shipping the vulnerable kernel versions and may impact container orchestration stability.

How an attack unfolds

An attacker with local access creates and exits threads in a way that places task_struct entries on the dying_tasks list, then races css_task_iter_next calls (for example via repeated reads of cgroup.procs) against the window where the task's usage count drops to zero, causing the iterator to resurrect and later use the freed object.

How to fix it

Update to a Linux kernel containing the fix that adds an extra usage-count check inside css_task_iter_next to skip tasks whose ->usage has reached zero; rebuild and reboot all affected hosts; apply distribution-specific backports once released.

How to confirm the fix worked

Confirm the kernel source contains the added loop in css_task_iter_next that skips de-used tasks on the dying_list; verify the patch commit appears in the running kernel's git log or changelog; test by exercising cgroup.procs reads during rapid thread exit under load.

Typical attack path

Obtain local unprivileged shell on target Linux system
Create threadgroup and trigger cgroup membership changes that populate dying_tasks
Rapidly perform operations that invoke css_task_iter_next while the target tasks are exiting
Trigger the usage==0 window to cause the iterator to call get_task_struct on a soon-to-be-freed object
Use the resulting dangling reference to corrupt kernel memory or redirect execution

How to detect it

Search kernel logs for unexpected oops or use-after-free warnings referencing task_struct or css_task_iter; examine audit logs for unusual patterns of cgroup.procs access by non-root processes around thread-exit events.

What your security team should do

Prioritize patching kernel packages on all multi-user and container-host systems within the next maintenance window
Monitor upstream stable and distribution security lists for the exact fixed kernel versions
Restrict untrusted local code execution until patches are applied
Review container runtime configurations to limit cgroup access where feasible

The record

In the Linux kernel, the following vulnerability has been resolved: cgroup: Avoid iteration of dying tasks with zero refcount The commit 260fbcb92bbea ("cgroup: Move dying_tasks cleanup from cgroup_task_release() to cgroup_task_free()") extended the lifetime of tasks on the dying_tasks list. The iterators have provision to go through dying_tasks because of dying threadgroup leaders or explicit CSS_TASK_ITER_WITH_DEAD, however, it was expected that such tasks can obtain a new reference (that is possible before cgroup_task_release()/put_task_struct_rcu_user()). The tasks after cgroup_task_release() and before cgroup_task_free() are subject to race when they may or may not have ->usage count > 0. The race window is between css_task_iter_next() invocations when css_set_lock is released and we may arrive at a new ->task_pos. The iterator should not attempt to resurrect tasks whose ->usage count dropped to zero. (When that happens, __put_task_struct_rcu_cb() is already imminent and the returned task_struct would could be used after free.) As for the fix, we cannot simply check the signal->live count of a task on the dying list because that won't distinguish regular zombies waiting to be reaped from RCU remnant tasks that are going to be free'd. Therefore add an extra check to rule out ->usage==0 tasks from any iteration. The repeat: loop in css_task_iter_advance() doesn't consider ->usage count, so add a new loop to css_task_iter_next() to skip de-used tasks on the dying_list. Rough illustration of the possible race R (reader of cgroup.procs) T (thread) L (group leader) --------------------------------- -------------------------------- -------------------------------- L exits, signal->live > 0 cgroup_task_dead(L) css_set_skip_task_iters() // skips only cset->tasks list_add_tail(&L->cg_list, &cset->dying_tasks) css_task_iter_next() take css_set_lock css_task_iter_advance() leader && signal->live != 0 => it->task_pos = &L->cg_list release css_set_lock T exits --signal->live == 0 cgroup_task_dead(T) // css_set_lock release_task(T) cgroup_task_release(T) release_task(L) // zap_leader cgroup_task_release(L) put_task_struct_rcu_user(L) ...RCU... put_task_struct(L) L->usage = 0 /* L still on dying_tasks */ ...RCU... __put_task_struct(L) css_task_iter_next() // another iteration take css_set_lock it->task_pos = &L->cg_list get_task_struct(L) => addition on 0 drop css_set_lock cgroup_task_free(L) css_set_skip_task_iters() // dying skip comes too late free_task(L) cgroup_procs_show() task_pid_vnr(L)

Affected packages

Ecosystem	Package	Introduced	Fixed