CVE-2026-53328

What it actually does

This is a local Linux kernel availability issue in the sched_ext cgroup task-migration path. When a sched_ext scheduler is loaded and cgroup controllers are toggled or migrated in a specific sequence, scx_cgroup_move_task() can encounter a legitimate NULL cgrp_moving_from value and trigger a kernel WARN. On systems configured to treat kernel warnings as fatal, such as with panic_on_warn enabled, this can escalate from a warning into a kernel panic and host outage. The issue does not provide confidentiality or integrity impact and does not directly grant privilege escalation; the primary impact is denial of service.

Why it matters to the business

A local user or workload with the ability to influence cgroup configuration or trigger the affected systemd/cgroup behavior may be able to destabilize a Linux host using sched_ext. In production, this can cause workload interruption, node reboots, failed jobs, or service degradation, especially on systems where kernel warnings trigger panics. The low EPSS score and absence from the CISA KEV catalog indicate no current evidence of broad exploitation, but Linux kernel flaws affecting availability should still be prioritized for sched_ext-enabled fleets and systems using aggressive kernel panic policies.

How an attack unfolds

An attacker first needs local access or the ability to run code in an environment that can exercise cgroup operations on a vulnerable Linux kernel. The vulnerable condition requires sched_ext to be active. The attacker then causes cgroup controller changes involving CPU and other controllers, such as memory or pids, in a sequence where the CPU cgroup state is recreated while a stale css remains referenced. During a later migration, the kernel processes a css-only migration where cgrp_moving_from is legitimately NULL. The vulnerable kernel path emits a WARN in scx_cgroup_move_task(). If the system is configured to continue after WARN, the observable result may be kernel log noise and task/cgroup disruption. If panic_on_warn or an equivalent policy is enabled, the WARN can trigger a kernel panic, crashing or rebooting the host.

How to fix it

Apply a Linux kernel update that includes the upstream fix for this sched_ext warning condition. Because no fixed package versions were provided, track the relevant kernel packages from the Linux distribution or vendor and upgrade to the first release that explicitly includes the fix for CVE-2026-53328 or the sched_ext change described as dropping the invalid WARN on NULL cgrp_moving_from in scx_cgroup_move_task(). Where immediate patching is not possible, reduce exposure by disabling sched_ext on systems that do not require it, avoiding experimental sched_ext schedulers on production hosts, and reviewing whether panic_on_warn is appropriate for availability-critical systems. Restrict local users and workloads from unnecessary cgroup delegation or controller manipulation wherever operationally feasible.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version against the vendor advisory or source tree containing the sched_ext fix. Validate that the active booted kernel is the patched version, not only that a patched package is installed. On test systems where sched_ext is intentionally used, reproduce the controller toggling scenario safely and confirm that the prior WARN at kernel/sched/ext.c:3227 or scx_cgroup_move_task() no longer appears. Also check that /proc/sys/kernel/panic_on_warn is set according to organizational policy and that production hosts are not unintentionally running sched_ext schedulers if they are not required.

Typical attack path

1. Obtain local code execution or control over a workload capable of interacting with cgroups on a vulnerable Linux host.
2. Confirm or rely on the presence of an active sched_ext scheduler.
3. Trigger cgroup controller changes, such as enabling CPU, toggling CPU off and on, and changing memory or pids subtree control settings.
4. Create or maintain task state that leaves a stale CPU css alive while later cgroup migration occurs.
5. Cause cgroup migration to enter scx_cgroup_move_task() with cgrp_moving_from set to NULL.
6. Trigger a kernel WARN and, on systems with panic-on-warning behavior, cause a kernel panic or reboot.

How to detect it

Look for evidence of prior exploitation or accidental triggering in kernel logs, persistent journal entries, crash dumps, and reboot history. Relevant sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, pstore, kdump/vmcore metadata, systemd journal boot records, and monitoring alerts for unexpected node reboots. Search for WARN traces involving scx_cgroup_move_task, sched_ext, cgroup_subtree_control_write, cgroup_update_dfl_csses, cgroup_migrate_execute, cpu_cgroup_attach, and sched_move_task. Correlate these events with local user sessions, container lifecycle events, cgroup controller changes, systemd user manager activity, or writes to cgroup.subtree_control containing '+cpu', '+memory', or '+pids'. If panic_on_warn is enabled, investigate any kernel panic or reboot immediately following these WARN traces. There are no known public exploit-specific payload markers from the provided intelligence; detections should focus on kernel warning stack traces and suspicious repeated cgroup manipulation preceding a crash.

• WARNING: at kernel/sched/ext.c:3227 scx_cgroup_move_task
• scx_cgroup_move_task+0xa8/0xb0
• sched_move_task+0x134/0x290
• cpu_cgroup_attach+0x39/0x70
• cgroup_migrate_execute+0x37d/0x450
• cgroup_update_dfl_csses+0x1e3/0x270
• cgroup_subtree_control_write+0x3e7/0x440
• sched_ext
• cgrp_moving_from NULL
• +cpu +memory +pids
• /sys/fs/cgroup/cgroup.subtree_control
• /proc/sys/kernel/panic_on_warn

What your security team should do

• Inventory Linux hosts running kernels with sched_ext support and identify where sched_ext schedulers are loaded or enabled.
• Prioritize patching for multi-user systems, container hosts, CI runners, Kubernetes nodes, and any production hosts where local workloads can influence cgroup behavior.
• Apply vendor kernel updates that include the fix, then reboot into the patched kernel and verify the active kernel version.
• Review panic_on_warn settings; avoid configurations that convert non-security kernel warnings into production outages unless explicitly required by policy.
• Restrict unnecessary cgroup delegation and controller writes by untrusted users or workloads.
• Monitor kernel logs for sched_ext WARN traces and unexpected reboots until all affected systems are remediated.
• Because this is not currently in KEV and has very low EPSS, prioritize based on actual sched_ext usage and local multi-tenant risk rather than internet exposure.