CVE-2026-43439
Received Received - Intake
Race Condition in Linux Kernel Cgroup Migration

Publication date: 2026-05-08

Last updated on: 2026-05-08

Assigner: 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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-08
Last Modified
2026-05-08
Generated
2026-05-09
AI Q&A
2026-05-08
EPSS Evaluated
N/A
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability involves a race condition in the Linux kernel's cgroup subsystem during task migration and iteration. When a task is moved from one cgroup to another, the internal lists tracking tasks are updated. However, if an iterator is currently traversing the task list, it may become invalid because the task has been moved to a different list. This causes the iterator to skip some tasks during iteration, leading to incomplete or incorrect task listings.

The issue arises because the iterator advances relative to the wrong list after the task is moved, causing some tasks to be skipped. The fix involves advancing all active iterators before unlinking the task from the original list, ensuring iteration continues correctly even when migration and iteration happen concurrently.

This race condition is difficult to trigger in normal operation but can be reproduced by artificially slowing down the cgroup process listing and migrating tasks concurrently.


How can this vulnerability impact me? :

This vulnerability can cause the cgroup process listing to intermittently skip some tasks during migration, leading to incomplete or inaccurate information about which tasks belong to a cgroup.

While this does not directly cause crashes or security breaches, it can result in misleading system monitoring or management data, potentially affecting system administrators' ability to accurately track and control processes within cgroups.

The race condition is rare and hard to trigger without special instrumentation, so the practical impact is limited but important for correctness in systems relying on accurate cgroup task information.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by reproducing the race condition between task migration and iteration in cgroups. One method involves artificially slowing down the cgroup_procs_show() function to observe if tasks are intermittently skipped during iteration.

  • Add a temporary delay knob via /sys/kernel/cgroup/cgroup_test to inject a delay into cgroup_procs_show().
  • Spawn three long-running tasks (for example, with PIDs 101, 102, and 103).
  • Create a test cgroup and move these tasks into it.
  • Enable a large delay using the /sys/kernel/cgroup/cgroup_test interface.
  • In one shell, read the cgroup.procs file from the test cgroup.
  • Within the delay window, in another shell, migrate one of the tasks (e.g., PID 102) by writing it to a different cgroup.procs file.

If the vulnerability is present, cgroup.procs may intermittently show only some of the tasks (e.g., PID 101) while skipping others (e.g., PID 103). After migration completes, reading the file again should show all tasks.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability has been fixed in the Linux kernel by adding a call to css_set_skip_task_iters() before unlinking a task from the tasks list during migration. To mitigate this vulnerability immediately, you should update your Linux kernel to a version that includes this fix.

Since the race window is very small and the issue is related to internal kernel cgroup task iteration, no specific configuration changes or workarounds are described. Applying the kernel patch or upgrading to a fixed kernel version is the recommended mitigation.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart