CVE-2026-99105: sched_ext: Fix stall when a task enqueued with SCX_ENQ_LAST lands back on its CPU's local DSQ

Published Oct 28, 2026

Updated

In the Linux kernel, the following vulnerability has been resolved:

schedext: Fix stall when a task enqueued with SCXENQLAST lands back on its CPU's local DSQ

With SCXOPSENQLAST, the last runnable task on a CPU is passed to ops.enqueue() instead of being kept running. Exiting tasks without SCXOPSENQEXITING, migration disabled tasks without SCXOPSENQMIGRATIONDISABLED and tasks on an offline rq skip ops.enqueue() and go straight to the local DSQ. This happens in putprevtaskscx() 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.

scxmitosis, which sets SCXOPSENQLAST without SCXOPSENQEXITING, hit this during mass cgroup teardown: exiting tasks stuck in exitmmap() for over 40 seconds.

A task put on the local DSQ runs, as anywhere else. If the SCXENQLAST enqueue left the task on this CPU's local DSQ, set needresched on the task being switched in, as proxyreschedidle() does. reschedcurr() would flag the task being put instead, and schedule() clears that right after the pick.

Affected Software

1 affected component

Linux Linux kernel

Event History

Oct 28, 2026

CVE Published

via MITRE·10:34 AM

Data Sourced

via MITRE·10:34 AM

Description

Data Sourced

via NVD·11:17 AM

Description

Frequently Asked Questions

Which systems are exposed to this scheduling stall?

Systems using sched_ext with SCX_OPS_ENQ_LAST are exposed when a task bypasses ops.enqueue() and is placed directly on its CPU's local dispatch queue. The described cases include exiting tasks when SCX_OPS_ENQ_EXITING is not enabled, migration-disabled tasks when SCX_OPS_ENQ_MIGRATION_DISABLED is not enabled, and tasks on an offline run queue.

What conditions trigger the stall?

The issue occurs when an SCX_ENQ_LAST enqueue leaves a task on the current CPU's local dispatch queue after scheduling has selected idle. The CPU can then remain idle despite the queued task until an unrelated wakeup reaches that CPU or the watchdog fires.

How might the issue appear operationally?

Affected tasks can remain queued without running for an extended period. The reported example involved mass cgroup teardown, where exiting tasks were stuck in exit_mmap() for more than 40 seconds.

Is there a configuration-based mitigation if the fix cannot be deployed immediately?

The described trigger depends on SCX_OPS_ENQ_LAST and on certain task categories bypassing ops.enqueue(). Avoiding SCX_OPS_ENQ_LAST, or enabling the relevant enqueue handling for exiting and migration-disabled tasks where applicable, may avoid the stated paths, but the data does not establish this as a complete mitigation.

CVE-2026-99105: sched_ext: Fix stall when a task enqueued with SCX_ENQ_LAST lands back on its CPU's local DSQ

Affected Software

Event History

Frequently Asked Questions

Which systems are exposed to this scheduling stall?

What conditions trigger the stall?

How might the issue appear operationally?

Is there a configuration-based mitigation if the fix cannot be deployed immediately?

Company

Resources

Contact

Frequently Asked Questions

Which systems are exposed to this scheduling stall?

What conditions trigger the stall?

How might the issue appear operationally?

Is there a configuration-based mitigation if the fix cannot be deployed immediately?