CVE-2026-43439: cgroup: fix race between task migration and iteration

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

From: Greg Kroah-Hartman <gregkh@kernel.org>

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

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

cgroup: fix race between task migration and iteration

When a task is migrated out of a css_set, cgroup_migrate_add_task()
first moves it from cset->tasks to cset->mg_tasks via:

    list_move_tail(&task->cg_list, &cset->mg_tasks);

If a css_task_iter currently has it->task_pos pointing to this task,
css_set_move_task() calls css_task_iter_skip() to keep the iterator
valid. However, since the task has already been moved to ->mg_tasks,
the iterator is advanced relative to the mg_tasks list instead of the
original tasks list. As a result, remaining tasks on cset->tasks, as
well as tasks queued on cset->mg_tasks, can be skipped by iteration.

Fix this by calling css_set_skip_task_iters() before unlinking
task->cg_list from cset->tasks. This advances all active iterators to
the next task on cset->tasks, so iteration continues correctly even
when a task is concurrently being migrated.

This race is hard to hit in practice without instrumentation, but it
can be reproduced by artificially slowing down cgroup_procs_show().
For example, on an Android device a temporary
/sys/kernel/cgroup/cgroup_test knob can be added to inject a delay
into cgroup_procs_show(), and then:

  1) Spawn three long-running tasks (PIDs 101, 102, 103).
  2) Create a test cgroup and move the tasks into it.
  3) Enable a large delay via /sys/kernel/cgroup/cgroup_test.
  4) In one shell, read cgroup.procs from the test cgroup.
  5) Within the delay window, in another shell migrate PID 102 by
     writing it to a different cgroup.procs file.

Under this setup, cgroup.procs can intermittently show only PID 101
while skipping PID 103. Once the migration completes, reading the
file again shows all tasks as expected.

Note that this change does not allow removing the existing
css_set_skip_task_iters() call in css_set_move_task(). The new call
in cgroup_migrate_add_task() only handles iterators that are racing
with migration while the task is still on cset->tasks. Iterators may
also start after the task has been moved to cset->mg_tasks. If we
dropped css_set_skip_task_iters() from css_set_move_task(), such
iterators could keep task_pos pointing to a migrating task, causing
css_task_iter_advance() to malfunction on the destination css_set,
up to and including crashes or infinite loops.

The race window between migration and iteration is very small, and
css_task_iter is not on a hot path. In the worst case, when an
iterator is positioned on the first thread of the migrating process,
cgroup_migrate_add_task() may have to skip multiple tasks via
css_set_skip_task_iters(). However, this only happens when migration
and iteration actually race, so the performance impact is negligible
compared to the correctness fix provided here.

The Linux kernel CVE team has assigned CVE-2026-43439 to this issue.


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

	Issue introduced in 5.2 with commit b636fd38dc40113f853337a7d2a6885ad23b8811 and fixed in 5.10.253 with commit 7c85debc35e6d131bd29c64f2ae78c6ede0e55c4
	Issue introduced in 5.2 with commit b636fd38dc40113f853337a7d2a6885ad23b8811 and fixed in 5.15.203 with commit 3b95abab7369235a37b15eaec6e1a0b443bba7c7
	Issue introduced in 5.2 with commit b636fd38dc40113f853337a7d2a6885ad23b8811 and fixed in 6.1.167 with commit 4a9654a2b46cfdaae287fb8995f536245635e467
	Issue introduced in 5.2 with commit b636fd38dc40113f853337a7d2a6885ad23b8811 and fixed in 6.6.130 with commit 3dfd1328c05234e8d8fa61948b2ba82680594988
	Issue introduced in 5.2 with commit b636fd38dc40113f853337a7d2a6885ad23b8811 and fixed in 6.12.78 with commit 9cca530c7cc1b3e02cb8fa7f80060dd4b38562ce
	Issue introduced in 5.2 with commit b636fd38dc40113f853337a7d2a6885ad23b8811 and fixed in 6.18.19 with commit 86ceaccfdfa16dad05addb33dc206e03589bcfd1
	Issue introduced in 5.2 with commit b636fd38dc40113f853337a7d2a6885ad23b8811 and fixed in 6.19.9 with commit 9dc76f6fc0d28d2382583715bc4ec22f28104845
	Issue introduced in 5.2 with commit b636fd38dc40113f853337a7d2a6885ad23b8811 and fixed in 7.0 with commit 5ee01f1a7343d6a3547b6802ca2d4cdce0edacb1
	Issue introduced in 4.14.138 with commit b0af004fd58ded5f898630db008c5b824c27d7db
	Issue introduced in 4.19.66 with commit 370b9e6399da09fe10005fe455878b356de7b85f

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-2026-43439
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:
	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/7c85debc35e6d131bd29c64f2ae78c6ede0e55c4
	https://git.kernel.org/stable/c/3b95abab7369235a37b15eaec6e1a0b443bba7c7
	https://git.kernel.org/stable/c/4a9654a2b46cfdaae287fb8995f536245635e467
	https://git.kernel.org/stable/c/3dfd1328c05234e8d8fa61948b2ba82680594988
	https://git.kernel.org/stable/c/9cca530c7cc1b3e02cb8fa7f80060dd4b38562ce
	https://git.kernel.org/stable/c/86ceaccfdfa16dad05addb33dc206e03589bcfd1
	https://git.kernel.org/stable/c/9dc76f6fc0d28d2382583715bc4ec22f28104845
	https://git.kernel.org/stable/c/5ee01f1a7343d6a3547b6802ca2d4cdce0edacb1