CVE-2026-93150

cgroup/cpuset: Make nr_deadline_tasks an atomic_t

N/A
Published: September 17, 2026 at 04:11 PM UTC
Updated: October 21, 2026 at 01:21 PM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
N/A
Exploit prediction
EPSS 0.2%

Description

In the Linux kernel, the following vulnerability has been resolved: cgroup/cpuset: Make nr_deadline_tasks an atomic_t The nr_deadline_tasks variable in the cpuset structure was introduced by commit 6c24849f5515 ("sched/cpuset: Keep track of SCHED_DEADLINE task in cpusets"). It is reported by sashiko [1] that nr_deadline_tasks can currently be modified by inc_dl_tasks_cs() under rq->lock and by cpuset_attach() under cpuset_mutex. So if both updates happen simultaneously, the nr_deadline_tasks variable can be corrupted leading to incorrect operations down the road. Fix that by changing its type to atomic_t so that nr_deadline_tasks are always atomically updated. This fix patch is a low hanging fruit. It can handle some of the races between a concurrent sched_setscheduler() and cpuset_can_attach()/cpuset_attach() calls, but not all of them like the other issue raised by sashiko [2]. This will be handled hopefully in a future follow up patch. [1] https://sashiko.dev/#/patchset/20260626181923.133658-1-longman%40redhat.com [2] https://sashiko.dev/#/patchset/20260630033344.352702-1-longman%40redhat.com

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

43d8cbfefa7c59bd3b5fe184535eca476d45304e5.10.1935.15.1295ac05ce5684315d0e71194a63febaf33921c32686.1.506.4.136.56c24849f5515e4966d94fa5279bdff4acf2e948974fac5bb0d375d6b8f5e7997925063c509089c9cd1b4262b78cc7638642833252ae92fc586854ffb
Vendor states this is fixed in 78d9daf5e13ad1448b7dfebac949936710ec7565 (fixed)
Vendor states this is fixed in 95220e1f18f6321008f021abc7d6f581f64bcb82 (fixed)
Vendor states this is fixed in e422b32e6a57269ca8164c60674a78bee85cf5fb (fixed)
Vendor states this is fixed in e5965ae3f7c918151b87e5c925b7978afbeaf638 (fixed)
Affected range stops below 5.11, so it looks safe — our inference, not a vendor statement
Affected range stops below 5.16, so it looks safe — our inference, not a vendor statement
Vendor states this is fixed in 6.12.110 (unaffected)
Vendor states this is fixed in 6.18.52 (unaffected)
Affected range stops below 6.2, so it looks safe — our inference, not a vendor statement
Vendor states this is fixed in 6.5 (unaffected)
Vendor states this is fixed in 6.6.160 (unaffected)
Vendor states this is fixed in 7.2.6 (unaffected)
Vendor states this is fixed in 7.3 (unaffected)
Vendor states this is fixed in 7.3-rc1 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card