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

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 cssset, cgroupmigrateaddtask() first moves it from cset->tasks to cset->mgtasks via:

listmovetail(&task->cglist, &cset->mgtasks);

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

Fix this by calling csssetskiptaskiters() before unlinking task->cglist 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 cgroupprocsshow(). For example, on an Android device a temporary /sys/kernel/cgroup/cgrouptest knob can be added to inject a delay into cgroupprocsshow(), 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/cgrouptest. 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 csssetskiptaskiters() call in csssetmovetask(). The new call in cgroupmigrateaddtask() 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->mgtasks. If we dropped csssetskiptaskiters() from csssetmovetask(), such iterators could keep taskpos pointing to a migrating task, causing csstaskiteradvance() to malfunction on the destination cssset, up to and including crashes or infinite loops.

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