CVE-2026-64525 in Linux
Сводка
по VulDB • 25.07.2026
В ядре Linux устранена следующая уязвимость:
xfrm: перенос синхронизации RCU для policy_bydst из обработчика .exit в .pre_exit на уровне каждого сетевого пространства имен (netns)
Документация к структуре pernet_operations в файле include/net/net_namespace.h явно предупреждает о недопустимости блокирующих операций с примитивами RCU в обработчиках .exit:
Методы выхода, использующие блокирующие примитивы RCU, такие как synchronize_rcu(), должны быть реализованы через exit_batch. [...]
По возможности следует полностью избегать использования synchronize_rcu().
Примечание: можно использовать комбинацию pre_exit() и exit(), поскольку между этими вызовами гарантируется выполнение synchronize_rcu().
Функция xfrm_policy_fini() нарушает это требование: она вызывает synchronize_rcu() перед освобождением хэш-таблиц policy_bydst (таким образом, на момент освобождения не остается читателей RCU в процессе обхода), но выполняется из обработчика xfrm_net_ops.exit — один раз для каждого сетевого пространства имен. В результате очистка cleanup_net() N сетевых пространств имен последовательно затрагивает N полных периодов гостеприимства (grace periods) RCU.
Использовать задокументированное разделение на pre_exit/exit. Перенести сброс политик (и очереди задач, от которых она зависит) в новый обработчик .pre_exit; затем xfrm_policy_fini() выполняется в .exit и освобождает хэш-таблицы после вызова synchronize_rcu_expedited(), который гарантируется cleanup_net() между двумя фазами. Это обеспечивает O(1) периодов гостеприимства RCU на пакет вместо O(N).
Наблюдалось в Linux 6.18 при рабочей нагрузке, выполняющей unshare(CLONE_NEWNET) со скоростью ~13 раз в секунду: cleanup_net() и kthread-резервист netns_wq оба зависали внутри synchronize_rcu() функции xfrm_policy_fini(), более 300 тыс. структур net накапливались в очереди очистки, объем Percpu в /proc/meminfo вырос до 130+ ГБ на хостах с 256 процессорами, после чего последовали ошибки OOM (Out Of Memory) для memcg. Счетчики setup_net и __put_net были сбалансированы, что исключало утечку счетчиков ссылок (refcount leak).
If you want to get best quality of vulnerability data, you may have to visit VulDB.