<?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://db.gcve.eu</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>Mon, 28 Sep 2026 19:46:07 +0000</lastBuildDate>
    <item>
      <title>CVE-2022-49647 — cgroup: Use separate src/dst nodes when preloading css_sets for migration</title>
      <link>https://db.gcve.eu/vuln/cve-2022-49647</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;cgroup: Use separate src/dst nodes when preloading css_sets for migration&lt;/p&gt;
&lt;p&gt;Each cset (css_set) is pinned by its tasks. When we&amp;#39;re moving tasks around
across csets for a migration, we need to hold the source and destination
csets to ensure that they don&amp;#39;t go away while we&amp;#39;re moving tasks about. This
is done by linking cset-&amp;gt;mg_preload_node on either the
mgctx-&amp;gt;preloaded_src_csets or mgctx-&amp;gt;preloaded_dst_csets list. Using the
same cset-&amp;gt;mg_preload_node for both the src and dst lists was deemed okay as
a cset can&amp;#39;t be both the source and destination at the same time.&lt;/p&gt;
&lt;p&gt;Unfortunately, this overloading becomes problematic when multiple tasks are
involved in a migration and some of them are identity noop migrations while
others are actually moving across cgroups. For example, this can happen with
the following sequence on cgroup1:&lt;/p&gt;
&lt;p&gt;#1&amp;gt; mkdir -p /sys/fs/cgroup/misc/a/b
 #2&amp;gt; echo $$ &amp;gt; /sys/fs/cgroup/misc/a/cgroup.procs
 #3&amp;gt; RUN_A_COMMAND_WHICH_CREATES_MULTIPLE_THREADS &amp;amp;
 #4&amp;gt; PID=$!
 #5&amp;gt; echo $PID &amp;gt; /sys/fs/cgroup/misc/a/b/tasks
 #6&amp;gt; echo $PID &amp;gt; /sys/fs/cgroup/misc/a/cgroup.procs&lt;/p&gt;
&lt;p&gt;the process including the group leader back into a. In this final migration,
non-leader threads would be doing identity migration while the group leader
is doing an actual one.&lt;/p&gt;
&lt;p&gt;After #3, let&amp;#39;s say the whole process was in cset A, and that after #4, the
leader moves to cset B. Then, during #6, the following happens:&lt;/p&gt;
&lt;p&gt;1. cgroup_migrate_add…&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;cgroup: Use separate src/dst nodes when preloading css_sets for migration&lt;/p&gt;
&lt;p&gt;Each cset (css_set) is pinned by its tasks. When we&amp;#39;re moving tasks around
across csets for a migration, we need to hold the source and destination
csets to ensure that they don&amp;#39;t go away while we&amp;#39;re moving tasks about. This
is done by linking cset-&amp;gt;mg_preload_node on either the
mgctx-&amp;gt;preloaded_src_csets or mgctx-&amp;gt;preloaded_dst_csets list. Using the
same cset-&amp;gt;mg_preload_node for both the src and dst lists was deemed okay as
a cset can&amp;#39;t be both the source and destination at the same time.&lt;/p&gt;
&lt;p&gt;Unfortunately, this overloading becomes problematic when multiple tasks are
involved in a migration and some of them are identity noop migrations while
others are actually moving across cgroups. For example, this can happen with
the following sequence on cgroup1:&lt;/p&gt;
&lt;p&gt;#1&amp;gt; mkdir -p /sys/fs/cgroup/misc/a/b
 #2&amp;gt; echo $$ &amp;gt; /sys/fs/cgroup/misc/a/cgroup.procs
 #3&amp;gt; RUN_A_COMMAND_WHICH_CREATES_MULTIPLE_THREADS &amp;amp;
 #4&amp;gt; PID=$!
 #5&amp;gt; echo $PID &amp;gt; /sys/fs/cgroup/misc/a/b/tasks
 #6&amp;gt; echo $PID &amp;gt; /sys/fs/cgroup/misc/a/cgroup.procs&lt;/p&gt;
&lt;p&gt;the process including the group leader back into a. In this final migration,
non-leader threads would be doing identity migration while the group leader
is doing an actual one.&lt;/p&gt;
&lt;p&gt;After #3, let&amp;#39;s say the whole process was in cset A, and that after #4, the
leader moves to cset B. Then, during #6, the following happens:&lt;/p&gt;
&lt;p&gt;1. cgroup_migrate_add…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2022-49647</guid>
    </item>
  </channel>
</rss>
