CVE-2026-43439 in Linux
Сводка
по VulDB • 22.05.2026
В ядре Linux устранена следующая уязвимость:
cgroup: исправлена гонка данных (race condition) между миграцией задачи и итерацией
Когда задача перемещается из css_set, функция cgroup_migrate_add_task() сначала перемещает её из cset->tasks в cset->mg_tasks с помощью:
list_move_tail(&task->cg_list, &cset->mg_tasks);
Если текущий итератор css_task_iter имеет указатель it->task_pos,指向 эту задачу, функция css_set_move_task() вызывает css_task_iter_skip() для сохранения корректности итератора. Однако, поскольку задача уже была перемещена в ->mg_tasks, итератор продвигается относительно списка mg_tasks, а не исходного списка tasks. В результате итерация может пропускать оставшиеся задачи в cset->tasks, а также задачи, находящиеся в очереди в cset->mg_tasks.
Исправление заключается в вызове css_set_skip_task_iters() перед удалением task->cg_list из cset->tasks. Это приводит к продвижению всех активных итераторов к следующей задаче в cset->tasks, поэтому итерация продолжается корректно даже при одновременной миграции задачи.
Эта гонка данных трудно реализуема на практике без использования инструментов отладки (инструментации), но её можно воспроизвести, искусственно замедлив работу функции cgroup_procs_show(). Например, на устройстве под управлением Android можно временно добавить параметр /sys/kernel/cgroup/cgroup_test для внедрения задержки в cgroup_procs_show(), а затем выполнить следующие действия:
1) Запустить три долгоживущие задачи (PID 101, 102, 103). 2) Создать тестовую cgroup и переместить задачи в неё. 3) Установить большую задержку через /sys/kernel/cgroup/cgroup_test. 4) В одной оболочке прочитать файл cgroup.procs из тестовой cgroup. 5) В течение окна задержки в другой оболочке переместить PID 102, записав его в файл cgroup.procs другой cgroup.
При такой настройке файл cgroup.procs может периодически отображать только PID 101, пропуская PID 103. После завершения миграции повторное чтение файла показывает все задачи, как и ожидалось.
Обратите внимание, что данное изменение не позволяет удалить существующий вызов css_set_skip_task_iters() в функции css_set_move_task(). Новый вызов в cgroup_migrate_add_task() обрабатывает только итераторы, участвующие в гонке данных с миграцией, пока задача всё ещё находится в cset->tasks. Итераторы также могут начинаться после того, как задача была перемещена в cset->mg_tasks. Если бы мы убрали вызов css_set_skip_task_iters() из css_set_move_task(), такие итераторы могли бы продолжать указывать task_pos на мигрирующую задачу, что привело бы к некорректной работе css_task_iter_advance() для целевого css_set, вплоть до аварийных завершений работы (crashes) или бесконечных циклов.
Окно гонки данных между миграцией и итерацией очень мало, и css_task_iter не находится на критическом пути выполнения (hot path). В худшем случае, когда итератор находится на первом потоке мигрирующего процесса, cgroup_migrate_add_task() может быть вынуждена пропускать несколько задач через css_set_skip_task_iters(). Однако это происходит только тогда, когда миграция и итерация действительно находятся в состоянии гонки данных, поэтому влияние на производительность является пренебрежимо малым по сравнению с исправлением корректности, предоставляемым в данном патче.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.