<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 29 Sep 2026 05:39:10 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-53328 — sched_ext: Don't warn on NULL cgrp_moving_from in scx_cgroup_move_task()</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-53328</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;sched_ext: Don&amp;#39;t warn on NULL cgrp_moving_from in scx_cgroup_move_task()&lt;/p&gt;
&lt;p&gt;A WARN fires when systemd&amp;#39;s user manager writes &amp;#34;+cpu +memory +pids&amp;#34; to
its own subtree_control while a sched_ext scheduler is loaded:&lt;/p&gt;
&lt;p&gt;WARNING: at kernel/sched/ext.c:3227 scx_cgroup_move_task+0xa8/0xb0
   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&lt;/p&gt;
&lt;p&gt;scx_cgroup_can_attach() arms cgrp_moving_from only when a task&amp;#39;s cpu
cgroup changes. It can still be NULL when scx_cgroup_move_task() runs,
through this sequence:&lt;/p&gt;
&lt;p&gt;Step                               Result
  ---------------------------------  ----------------------------------
  1. cpu enabled on cgroup G         cpu css = A
  2. cpu toggled off then on for G   A killed, B created (same cgroup)
  3. an exiting task keeps A alive   migration skips it, A now stale
  4. +memory migrates G              stale A vs current B pulls cpu in
  5. cpu attach runs for all tasks   hits a live, cpu-unchanged task
  6. scx_cgroup_move_task() on it    cgrp_moving_from NULL -&amp;gt; WARN&lt;/p&gt;
&lt;p&gt;The mismatch is that scx_cgroup_can_attach() keys on cgroup identity
while migration drives the move on css identity, so a NULL cgrp_moving_from
here is a legitimate css-only migration, not a missing prep.&lt;/p&gt;
&lt;p&gt;The call is already gated on cgrp_moving_from, so…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;sched_ext: Don&amp;#39;t warn on NULL cgrp_moving_from in scx_cgroup_move_task()&lt;/p&gt;
&lt;p&gt;A WARN fires when systemd&amp;#39;s user manager writes &amp;#34;+cpu +memory +pids&amp;#34; to
its own subtree_control while a sched_ext scheduler is loaded:&lt;/p&gt;
&lt;p&gt;WARNING: at kernel/sched/ext.c:3227 scx_cgroup_move_task+0xa8/0xb0
   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&lt;/p&gt;
&lt;p&gt;scx_cgroup_can_attach() arms cgrp_moving_from only when a task&amp;#39;s cpu
cgroup changes. It can still be NULL when scx_cgroup_move_task() runs,
through this sequence:&lt;/p&gt;
&lt;p&gt;Step                               Result
  ---------------------------------  ----------------------------------
  1. cpu enabled on cgroup G         cpu css = A
  2. cpu toggled off then on for G   A killed, B created (same cgroup)
  3. an exiting task keeps A alive   migration skips it, A now stale
  4. +memory migrates G              stale A vs current B pulls cpu in
  5. cpu attach runs for all tasks   hits a live, cpu-unchanged task
  6. scx_cgroup_move_task() on it    cgrp_moving_from NULL -&amp;gt; WARN&lt;/p&gt;
&lt;p&gt;The mismatch is that scx_cgroup_can_attach() keys on cgroup identity
while migration drives the move on css identity, so a NULL cgrp_moving_from
here is a legitimate css-only migration, not a missing prep.&lt;/p&gt;
&lt;p&gt;The call is already gated on cgrp_moving_from, so…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-53328</guid>
    </item>
  </channel>
</rss>
