lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <2025022619-CVE-2022-49647-b3cb@gregkh>
Date: Wed, 26 Feb 2025 03:23:30 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: CVE-2022-49647: cgroup: Use separate src/dst nodes when preloading css_sets for migration

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

cgroup: Use separate src/dst nodes when preloading css_sets for migration

Each cset (css_set) is pinned by its tasks. When we're moving tasks around
across csets for a migration, we need to hold the source and destination
csets to ensure that they don't go away while we're moving tasks about. This
is done by linking cset->mg_preload_node on either the
mgctx->preloaded_src_csets or mgctx->preloaded_dst_csets list. Using the
same cset->mg_preload_node for both the src and dst lists was deemed okay as
a cset can't be both the source and destination at the same time.

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:

 #1> mkdir -p /sys/fs/cgroup/misc/a/b
 #2> echo $$ > /sys/fs/cgroup/misc/a/cgroup.procs
 #3> RUN_A_COMMAND_WHICH_CREATES_MULTIPLE_THREADS &
 #4> PID=$!
 #5> echo $PID > /sys/fs/cgroup/misc/a/b/tasks
 #6> echo $PID > /sys/fs/cgroup/misc/a/cgroup.procs

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.

After #3, let'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:

 1. cgroup_migrate_add_src() is called on B for the leader.

 2. cgroup_migrate_add_src() is called on A for the other threads.

 3. cgroup_migrate_prepare_dst() is called. It scans the src list.

 4. It notices that B wants to migrate to A, so it tries to A to the dst
    list but realizes that its ->mg_preload_node is already busy.

 5. and then it notices A wants to migrate to A as it's an identity
    migration, it culls it by list_del_init()'ing its ->mg_preload_node and
    putting references accordingly.

 6. The rest of migration takes place with B on the src list but nothing on
    the dst list.

This means that A isn't held while migration is in progress. If all tasks
leave A before the migration finishes and the incoming task pins it, the
cset will be destroyed leading to use-after-free.

This is caused by overloading cset->mg_preload_node for both src and dst
preload lists. We wanted to exclude the cset from the src list but ended up
inadvertently excluding it from the dst list too.

This patch fixes the issue by separating out cset->mg_preload_node into
->mg_src_preload_node and ->mg_dst_preload_node, so that the src and dst
preloadings don't interfere with each other.

The Linux kernel CVE team has assigned CVE-2022-49647 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 3.16 with commit f817de98513d060023be4fa1d061b29a6515273e and fixed in 4.14.289 with commit 05f7658210d1d331e8dd4cb6e7bbbe3df5f5ac27
	Issue introduced in 3.16 with commit f817de98513d060023be4fa1d061b29a6515273e and fixed in 4.19.253 with commit cec2bbdcc14fbaa6b95ee15a7c423b05d97038be
	Issue introduced in 3.16 with commit f817de98513d060023be4fa1d061b29a6515273e and fixed in 5.4.207 with commit ad44e05f3e016bdcb1ad25af35ade5b5f41ccd68
	Issue introduced in 3.16 with commit f817de98513d060023be4fa1d061b29a6515273e and fixed in 5.10.132 with commit 7657e3958535d101a24ab4400f9b8062b9107cc4
	Issue introduced in 3.16 with commit f817de98513d060023be4fa1d061b29a6515273e and fixed in 5.15.56 with commit 54aee4e5ce8c21555286a6333e46c1713880cf93
	Issue introduced in 3.16 with commit f817de98513d060023be4fa1d061b29a6515273e and fixed in 5.18.13 with commit 0e41774b564befa6d271e8d5086bf870d617a4e6
	Issue introduced in 3.16 with commit f817de98513d060023be4fa1d061b29a6515273e and fixed in 5.19 with commit 07fd5b6cdf3cc30bfde8fe0f644771688be04447

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2022-49647
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	include/linux/cgroup-defs.h
	kernel/cgroup/cgroup.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/05f7658210d1d331e8dd4cb6e7bbbe3df5f5ac27
	https://git.kernel.org/stable/c/cec2bbdcc14fbaa6b95ee15a7c423b05d97038be
	https://git.kernel.org/stable/c/ad44e05f3e016bdcb1ad25af35ade5b5f41ccd68
	https://git.kernel.org/stable/c/7657e3958535d101a24ab4400f9b8062b9107cc4
	https://git.kernel.org/stable/c/54aee4e5ce8c21555286a6333e46c1713880cf93
	https://git.kernel.org/stable/c/0e41774b564befa6d271e8d5086bf870d617a4e6
	https://git.kernel.org/stable/c/07fd5b6cdf3cc30bfde8fe0f644771688be04447

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ