Cloudanix VulnDB

CVE-2026-99105

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A scheduling bug can leave work sitting on a processor that thinks it has nothing to do, causing noticeable slowdowns or freezes until something else wakes the processor.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

A race in sched_ext's handling of SCX_ENQ_LAST enqueues leaves a runnable task on a CPU's local DSQ without triggering a reschedule, causing the CPU to idle until an unrelated wakeup or watchdog occurs.

Why it matters to the business

Systems using sched_ext schedulers with ENQ_LAST can experience prolonged task stalls, leading to application delays, cgroup teardown failures, and potential watchdog-induced resets that disrupt workloads.

How an attack unfolds

An attacker with local access crafts or triggers workloads that cause tasks to be enqueued via SCX_ENQ_LAST without ENQ_EXITING or migration flags, landing them on the local DSQ after the idle pick has completed so the CPU idles with work queued.

How to fix it

Apply the upstream sched_ext fix that sets need_resched on the incoming task when an SCX_ENQ_LAST enqueue leaves work on the local DSQ; rebuild and deploy the patched kernel across all affected hosts.

How to confirm the fix worked

Boot the patched kernel, reproduce the SCX_OPS_ENQ_LAST enqueue scenarios including mass cgroup teardown, and confirm that tasks no longer remain queued on a local DSQ without immediate rescheduling.

Typical attack path

  1. Obtain local execution on a system running a sched_ext scheduler that sets SCX_OPS_ENQ_LAST
  2. Trigger mass task creation and exit patterns such as cgroup teardown that bypass ops.enqueue()
  3. Leave exiting or migration-disabled tasks on the local DSQ after pick_idle settles
  4. Observe CPU stall until watchdog or external wakeup occurs

How to detect it

Review kernel logs for watchdog timer firings or unusually long exit_mmap delays; inspect sched_ext tracepoints around put_prev_task_scx and enqueue operations for tasks left on local DSQs without immediate reschedule events.

What your security team should do

  • Prioritize kernel update on any hosts running sched_ext with SCX_OPS_ENQ_LAST
  • Monitor for unexplained CPU idle periods coinciding with task exit or cgroup operations
  • Test sched_ext-based schedulers in staging before production rollout

The record

In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix stall when a task enqueued with SCX_ENQ_LAST lands back on its CPU's local DSQ With SCX_OPS_ENQ_LAST, the last runnable task on a CPU is passed to ops.enqueue() instead of being kept running. Exiting tasks without SCX_OPS_ENQ_EXITING, migration disabled tasks without SCX_OPS_ENQ_MIGRATION_DISABLED and tasks on an offline rq skip ops.enqueue() and go straight to the local DSQ. This happens in put_prev_task_scx() after the pick has settled on idle, so nothing reschedules the CPU, which idles with the task queued until an unrelated wakeup lands on it or the watchdog fires. scx_mitosis, which sets SCX_OPS_ENQ_LAST without SCX_OPS_ENQ_EXITING, hit this during mass cgroup teardown: exiting tasks stuck in exit_mmap() for over 40 seconds. A task put on the local DSQ runs, as anywhere else. If the SCX_ENQ_LAST enqueue left the task on this CPU's local DSQ, set need_resched on the task being switched in, as proxy_resched_idle() does. resched_curr() would flag the task being put instead, and __schedule() clears that right after the pick.

Affected packages

Ecosystem Package Introduced Fixed