CVE-2026-53328

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched_ext: Don&amp;#39;t warn on NULL cgrp_moving_from in scx_cgroup_move_task()<br /> <br /> A WARN fires when systemd&amp;#39;s user manager writes "+cpu +memory +pids" to<br /> its own subtree_control while a sched_ext scheduler is loaded:<br /> <br /> WARNING: at kernel/sched/ext.c:3227 scx_cgroup_move_task+0xa8/0xb0<br /> scx_cgroup_move_task+0xa8/0xb0<br /> sched_move_task+0x134/0x290<br /> cpu_cgroup_attach+0x39/0x70<br /> cgroup_migrate_execute+0x37d/0x450<br /> cgroup_update_dfl_csses+0x1e3/0x270<br /> cgroup_subtree_control_write+0x3e7/0x440<br /> <br /> scx_cgroup_can_attach() arms cgrp_moving_from only when a task&amp;#39;s cpu<br /> cgroup changes. It can still be NULL when scx_cgroup_move_task() runs,<br /> through this sequence:<br /> <br /> Step Result<br /> --------------------------------- ----------------------------------<br /> 1. cpu enabled on cgroup G cpu css = A<br /> 2. cpu toggled off then on for G A killed, B created (same cgroup)<br /> 3. an exiting task keeps A alive migration skips it, A now stale<br /> 4. +memory migrates G stale A vs current B pulls cpu in<br /> 5. cpu attach runs for all tasks hits a live, cpu-unchanged task<br /> 6. scx_cgroup_move_task() on it cgrp_moving_from NULL -&gt; WARN<br /> <br /> The mismatch is that scx_cgroup_can_attach() keys on cgroup identity<br /> while migration drives the move on css identity, so a NULL cgrp_moving_from<br /> here is a legitimate css-only migration, not a missing prep.<br /> <br /> The call is already gated on cgrp_moving_from, so just drop the warning.<br /> ops.cgroup_prep_move() and ops.cgroup_move() stay paired.