CVE-2026-98163

HIGHNVD 7.07.0—
EchelonGraph scoreHIGH confidence

Score 7.0 from GitHub Security Advisory (severity: HIGH) published 2026-09-26. NVD baseline CVSS 7.0; sources differ by 0.0.

Triggered by: GitHub Security Advisory CVSS
Sources: epss, ghsa, nvd
Trending — 4 sources updated this week
7.0EG
EchelonGraph verdictPlan mitigationSerious severity, but no confirmed exploitation yet.
  • High severity, but no confirmed exploitation yet
CISA-KEV: Not listedEPSS PROB: 0.1%CVSS: 7.0Exploit: None knownExposed services: Not assessed

No fix is confirmed yet — apply a workaround or compensating control (WAF / firewall / segmentation) and watch for the fix.

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)

CVSS v3
7.0
EG Score
7.0HIGHhigh confidence
EG Risk
36
EG Risk 36/100CISA SSVC

EG Risk is EchelonGraph's 0–100 priority score: it fuses intrinsic severity with real-world exploitation and automatability so you can rank equal-severity CVEs and fix the most dangerous first. Higher = act sooner. Distinct from the 0–10 EG Score (severity).

How it’s computed
Severity70% × 45%
Exploitation0% × 40%
Automatability30% × 15%
CISA SSVC: Track at low or medium mission impact; Track or Attend at high (mission-essential systems).
Action: No fix is confirmed yet. Restrict network exposure of the affected system or apply the vendor's mitigation within your standard update timelines at low or medium mission impact and sooner than that at high, and watch the vendor's advisory for the fix.
EPSS PROB
0.1%
EPSS %ILE
below the 1st
KEV
Not listed

CISA SSVCTrack at low or medium mission impact; Track or Attend at high (mission-essential systems).

No fix is confirmed yet. Restrict network exposure of the affected system or apply the vendor's mitigation within your standard update timelines at low or medium mission impact and sooner than that at high, and watch the vendor's advisory for the fix.

Exploitation none (no KEV listing, exploit record or EPSS ≥ 50%) · Automatable unknown (not published for this CVE) · Technical impact partial (CVSS below 9.0). Mission impact is CISA's Mission & Well-being decision point, and only you can judge it: high means the affected system is essential to your organisation's mission, or its compromise could cause irreversible harm to people. CISA's decision table

Published

September 26, 2026

Last Modified

October 2, 2026

Advisory Details (2)

Auto-updated Oct 2, 2026
No patch confirmed yet.
generic

cgroup: Avoid iteration of dying tasks with zero refcount - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/828938118d6c2bb711301748c3e39e4bed6a62f5
generic

cgroup: Avoid iteration of dying tasks with zero refcount - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/057dac23d329d5c5ed62352f2659a39fd46c6d4a

Vendor Advisories for CVE-2026-98163(1)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Affected Packages

(1 across 1 ecosystem)
Debian:14(1)
PackageVulnerable rangeFix by version rangeDependents
linux6.12.100-1 ... 7.2~rc7-1~exp1 (180 versions)
  • every version up to 7.2.8-1: fixed in 7.2.8-1
—

Weakness Classification(2)

MITRE Common Weakness Enumeration — the root-cause categories this CVE belongs to.

Data Freshness Timeline

(refreshed 18× in last 7d / 23× in last 30d)

Each row is a source pipeline that fetched or updated this CVE on that date, with what changed. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. Most recent first.

  1. 2026-10-04 22:42 UTCGHSA enrichment
  2. 2026-10-04 10:19 UTCGHSA enrichment
  3. 2026-10-03 21:55 UTCEG score recompute
  4. 2026-10-03 21:55 UTCGHSA enrichment
  5. 2026-10-03 14:26 UTCEPSS rescore
  6. 2026-10-03 09:24 UTCEG score recompute
  7. 2026-10-03 09:24 UTCGHSA enrichment
  8. 2026-10-02 21:00 UTCEG score recompute▲ 7.00
  9. 2026-10-02 21:00 UTCGHSA enrichment
  10. 2026-10-02 21:00 UTCNVD updateCVSS v3 → 7 · severity → HIGH
  11. 2026-10-02 17:57 UTCEPSS rescore
  12. 2026-10-01 19:51 UTCEPSS rescore
  13. 2026-09-30 15:04 UTCEPSS rescore
  14. 2026-09-30 14:31 UTCGHSA enrichment
  15. 2026-09-29 13:25 UTCEG score recompute
  16. 2026-09-29 13:25 UTCGHSA enrichment
  17. 2026-09-28 13:52 UTCEPSS rescore
  18. 2026-09-28 13:52 UTCEPSS rescore
  19. 2026-09-27 13:49 UTCEPSS rescore
  20. 2026-09-26 15:59 UTCEPSS rescore
  21. 2026-09-26 09:17 UTCNVD update
  22. 2026-09-26 08:36 UTCEG score recompute
  23. 2026-09-26 08:35 UTCMITRE cvelistV5first tracked

Frequently asked(5)

What is CVE-2026-98163?
CVE-2026-98163 is a high vulnerability published on September 26, 2026. 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 cgrouptaskrelease() to cgrouptaskfree()") extended the lifetime of tasks on the dying_tasks list. The…
When was CVE-2026-98163 disclosed?
CVE-2026-98163 was first published on September 26, 2026, with the most recent update on October 2, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
Is CVE-2026-98163 actively exploited?
CVE-2026-98163 is not currently on CISA's Known Exploited Vulnerabilities catalog. FIRST EPSS estimates a 0.1% probability of exploitation in the next 30 days (below the 1st percentile of EPSS-scored CVEs).
What is the CVSS score of CVE-2026-98163?
CVE-2026-98163 has a CVSS v3 base score of 7.0 (NVD).
How do I remediate CVE-2026-98163?
No fix for CVE-2026-98163 is confirmed yet. Until one is published, restrict network exposure of the affected system or apply the vendor's mitigation — for example, keep it off the internet or limit it to trusted networks — and watch the vendor's advisory for the fix. The vendor advisories EchelonGraph has for CVE-2026-98163 are linked in the Vendor Advisories panel on this page.

Dependency Blast Radius

See which npm, PyPI, Go, and Maven packages are affected by CVE-2026-98163

Explore →

Is Your Infrastructure Affected by CVE-2026-98163?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.