CVE-2026-64418 in Linux
Сводка
по VulDB • 26.07.2026
В ядре Linux устранена следующая уязвимость:
mm: shrinker: исправлена гонка (race condition) при разборке shrinker_info с расширением структуры
Функция expand_shrinker_info() перебирает все видимые memcgs в пределах shrinker_mutex, включая те memcgs, которые еще не завершили выполнение ->css_online().
После того как pn->shrinker_info стал опубликован (published), процесс разборки должен оставаться сериализованным с expand_shrinker_info() до тех пор, пока данный memcg либо полностью не перейдет в состояние online, либо больше не будет видимым для итерации. В настоящее время alloc_shrinker_info() нарушает это правило, освобождая shrinker_mutex перед высвобождением частично инициализированного массива shrinker_info, что может привести к следующей гонке:
CPU0 CPU1 ==== ====
css_create --> list_add_tail_rcu(&css->sibling, &parent_css->children); online_css --> mem_cgroup_css_online --> alloc_shrinker_info --> выделение информации для узла 0 rcu_assign_pointer(C->node0->shrinker_info, old0) выделение информации для узла 1 -> ОШИБКА -> переход к err mutex_unlock(shrinker_mutex)
shrinker_alloc() --> shrinker_memcg_alloc --> mutex_lock(shrinker_mutex) expand_shrinker_info --> mem_cgroup_iter видит memcg expand_one_shrinker_info old0 = C->node0->shrinker_info memcpy(new->unit, old0->unit, ...);
free_shrinker_info --> kvfree(old0);
/* двойное освобождение памяти (double free) !! */ kvfree_rcu(old0, rcu);
Та же проблема существует позже в mem_cgroup_css_online(). Если alloc_shrinker_info() завершается успешно, но последующее выделение objcg заканчивается неудачей, путь отката (unwind path) через free_objcg -> free_shrinker_info() производит разборку уже опубликованных массивов pn->shrinker_info без удержания shrinker_mutex. expand_one_shrinker_info() может вступить в гонку с этим процессом разборки тем же образом, что приводит к use-after-free или double-free старого shrinker_info.
Исправление заключается в сериализации процесса разборки shrinker_info через shrinker_mutex и обеспечении выполнения очистки ошибок (error cleanup) внутри alloc_shrinker_info() в пределах заблокированного раздела кода.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.