CVE-2026-53328: Linux Kernel sched_ext Warning Vulnerability

CVE-2026-53328 Overview

CVE-2026-53328 affects the Linux kernel's sched_ext (extensible scheduler class) subsystem. A WARN fires inside scx_cgroup_move_task() when systemd's user manager writes +cpu +memory +pids to its own subtree_control while a sched_ext scheduler is loaded. The warning triggers because scx_cgroup_can_attach() keys on cgroup identity, while cgroup migration drives the move on cgroup subsystem state (css) identity. A NULLcgrp_moving_from in this path is a legitimate css-only migration rather than a missing preparation step. The fix removes the spurious warning while leaving ops.cgroup_prep_move() and ops.cgroup_move() correctly paired.

Critical Impact
The condition produces a kernel WARNING splat that pollutes logs and can trigger panic_on_warn reboots on hardened systems running a sched_ext scheduler alongside systemd cgroup v2 delegation.

Affected Products

Linux kernel builds with CONFIG_SCHED_CLASS_EXT enabled
Systems running a sched_ext BPF scheduler under systemd with cgroup v2
Distributions carrying the pre-patch kernel/sched/ext.c implementation

Discovery Timeline

2026-07-01 - CVE-2026-53328 published to NVD
2026-07-01 - Last updated in NVD database

Technical Details for CVE-2026-53328

Vulnerability Analysis

The defect lives in the sched_ext cgroup attach path at kernel/sched/ext.c:3227. scx_cgroup_can_attach() arms cgrp_moving_from only when a task's cpu cgroup changes. scx_cgroup_move_task() then asserts this pointer is non-NULL, but the invariant does not hold across css-only migrations. The kernel's own trace shows the path: scx_cgroup_move_task+0xa8/0xb0 → sched_move_task → cpu_cgroup_attach → cgroup_migrate_execute → cgroup_update_dfl_csses → cgroup_subtree_control_write. The subsequent call is already gated on cgrp_moving_from, so the warning fires without any correctness impact on the scheduler operations.

Root Cause

The root cause is a mismatched identity model between preparation and execution. scx_cgroup_can_attach() decides whether to record cgrp_moving_from based on cgroup identity, while cgroup_migrate_execute() iterates tasks by css identity. When a cpu controller is toggled off and back on for a cgroup, the original css A is killed and a new css B is created for the same cgroup. An exiting task can keep A alive as stale state. A later +memory migration on that cgroup pulls the cpu controller in with the stale-vs-current mismatch, causing the attach step to enumerate a task whose cgroup did not change but whose css did. The prep step is legitimately skipped, yet the assert still fires.

Attack Vector

The condition is triggered by ordinary local workload behavior: a sched_ext BPF scheduler must be loaded, and an unprivileged process such as the systemd --user manager must write to subtree_control on its own cgroup subtree. There is no known remote or privilege-escalation vector. On kernels booted with panic_on_warn, the warning escalates to a kernel panic, producing a local denial-of-service. The vulnerability manifests as a logic assertion mismatch rather than a memory-safety issue, so no exploitation primitive exists. See the upstream fix commit for the reasoning behind dropping the warning.

Detection Methods for CVE-2026-53328

Indicators of Compromise

Kernel log entries containing WARNING: at kernel/sched/ext.c:3227 scx_cgroup_move_task
Call traces including scx_cgroup_move_task, sched_move_task, cpu_cgroup_attach, and cgroup_subtree_control_write
Unexpected reboots on hosts booted with panic_on_warn=1 while a sched_ext scheduler is loaded

Detection Strategies

Query dmesg and journalctl -k for the scx_cgroup_move_task warning signature after sched_ext scheduler loads.
Correlate warning timestamps with systemd cgroup writes to cgroup.subtree_control under /sys/fs/cgroup/user.slice/.
Track kernel version and CONFIG_SCHED_CLASS_EXT status across the fleet to identify hosts that still carry the pre-patch code.

Monitoring Recommendations

Forward kernel ring buffer output to a centralized log platform and alert on sched_extWARN signatures.
Monitor sched_ext scheduler load and unload events via bpftool or auditd to correlate with warning occurrences.
Track host uptime regressions on nodes configured with panic_on_warn to catch panic-induced reboots.

How to Mitigate CVE-2026-53328

Immediate Actions Required

Apply the upstream sched_ext patch that removes the spurious WARN in scx_cgroup_move_task().
Rebuild and deploy kernels from the fixed stable branches referenced in the kernel.org commits.
Disable panic_on_warn on hosts that cannot be patched immediately to prevent the warning from escalating to a panic.

Patch Information

The fix is available in the following upstream commits: 02e545c4297a, 0ffcad63b19a, bc75f5951fac, and cdff2eb97be1. The change drops the warning while preserving the existing cgrp_moving_from gating, keeping ops.cgroup_prep_move() and ops.cgroup_move() paired.

Workarounds

Unload any sched_ext BPF scheduler on affected hosts until the patched kernel is deployed.
Set sysctl kernel.panic_on_warn=0 to prevent panics until the fix is installed.
Avoid programmatic writes to cgroup.subtree_control that add +cpu alongside other controllers while sched_ext is active.

bash

# Disable panic_on_warn until the patched kernel is deployed
sudo sysctl -w kernel.panic_on_warn=0

# Verify sched_ext scheduler state and unload if present
cat /sys/kernel/sched_ext/state
sudo bpftool struct_ops unregister name <scx_ops_name>

# Confirm kernel version includes the fix
uname -r