CVE-2026-64525 in Linux
Zusammenfassung
von VulDB • 25.07.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
xfrm: Verschieben der RCU-Synchronisierung von policy_bydst vom per-Netns .exit-Hook in den .pre_exit-Hook
Die Docstring für die Struktur `pernet_operations` in include/net/net_namespace.h warnt ausdrücklich davor, blockierende RCU-Primitiven in `.exit`-Handlern zu verwenden:
Exit-Methoden, die blockierende RCU-Primitiven wie synchronize_rcu() verwenden, sollten über exit_batch implementiert werden. [...]
Bitte vermeiden Sie synchronize_rcu(), wo immer möglich.
Beachten Sie, dass eine Kombination aus pre_exit() und exit() verwendet werden kann, da zwischen den Aufrufen ein synchronize_rcu() garantiert ist.
xfrm_policy_fini() verstößt gegen diese Regel: Es ruft synchronize_rcu() auf, bevor die policy_bydst-Hash-Tabellen freigegeben werden (so dass sich zum Zeitpunkt der Freigabe kein RCU-Leser mehr im Durchlauf befindet), wird jedoch aus xfrm_net_ops.exit -- einmal pro Namespace -- ausgeführt. Daher verursacht eine cleanup_net()-Operation für N Namespaces N volle RCU-Gnadenfristen seriell.
Verwenden Sie die dokumentierte Aufteilung in pre_exit/exit. Verschieben Sie das Leeren der Richtlinien (und den Workqueue, von dem dies abhängt) in einen neuen .pre_exit-Handler; xfrm_policy_fini() wird dann in .exit ausgeführt und gibt die Hash-Tabellen nach dem synchronize_rcu_expedited(), das cleanup_net() zwischen den beiden Phasen garantiert, frei. Dies bietet O(1)-RCU-Gnadenfristen pro Batch anstelle von O(N).
Beobachtet auf Linux 6.18 mit einer Arbeitslast, die unshare(CLONE_NEWNET) mit ~13/sec durchführte: cleanup_net() und der netns_wq-Rescuer-kthread steckten beide in synchronize_rcu() von xfrm_policy_fini(), >300k struct net-Ansammlungen stapelten sich in der Bereinigungswarteschlange, Percpu stieg in /proc/meminfo auf 130+ GB bei Hosts mit 256 CPUs an und es folgten memcg-OOM-Fälle (Out of Memory). Die Zählwerte für setup_net und __put_net waren ausgeglichen, was einen Refcount-Leck ausschließt.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.