---
id: "CVE-2026-99105"
kind: "vulnerability"
aliases: ["CVE-2026-99105"]
title: "Linux kernel: sched_ext task can sit queued and stall a CPU"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["kernel", "linux", "runtime", "sched-ext"]
not_affected_if: ["default-scheduler"]
published_at: "2026-10-28T11:17:29+00:00"
first_seen_at: "2026-10-28T11:32:34+00:00"
updated_at: "2026-10-28T11:37:50+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99105", "first_seen_at": "2026-10-28T11:32:34+00:00"}]
---

# Linux kernel: sched_ext task can sit queued and stall a CPU

In the Linux kernel's sched_ext scheduler, a task enqueued with the SCX_ENQ_LAST flag can be placed on its CPU's local queue without the CPU being told to reschedule, so the CPU stays idle with the task waiting. The sources describe this as a stall that lasts until an unrelated wakeup or the watchdog fires, and report exiting tasks stuck for over 40 seconds under scx_mitosis; they do not describe a way for an attacker to gain access.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- unknown

## Fix

- unknown

## Timeline

- 2026-10-28T11:32:34+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-99105

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_