Linux kernel (net/xfrm): The policy-hash rebuild preallocates for exactly the wrong half of the policy set - the guard

CVSS 6.5CVE-2026-64579Kernel, userspace & hypervisorcurated

Impact

The policy-hash rebuild preallocates for exactly the wrong half of the policy set - the guard is inverted, so the inexact policies (the ones whose reinsert actually allocates) are skipped. When the GFP_ATOMIC allocation then fails mid-rebuild the code only warns and continues, leaving a policy with a poisoned list node: it is neither properly on the inexact chain nor off it. Two consequences for an operator - a policy that should have matched can stop matching, so traffic that was supposed to be tunnelled leaves in clear, and the next rebuild dereferences LIST_POISON2 and panics the node.

Who can reach it

The rebuild is queued by XFRM_MSG_NEWSPDINFO or a policy-threshold change, which needs CAP_NET_ADMIN - host root or a tenant container holding it in its own user+network namespace. The second ingredient is an atomic allocation failure during the rebuild, which is deterministic under failslab and realistically reachable under genuine memory pressure; on a shared node a co-tenant can supply that pressure. Requires a non-trivial number of inexact policies installed.

What to do

Boot a kernel carrying the fix commits below (no fixed stable version published). Interim control: deny CAP_NET_ADMIN in tenant user namespaces so tenants cannot trigger rebuilds, and keep memory headroom on nodes running IPsec so atomic allocations do not fail.

References

https://git.kernel.org/stable/c/e48f4c3e3df35b34be719d72d737bbeaca77cf0c https://git.kernel.org/stable/c/1cdeed9df1306f1a277e715600772640d63defa9 https://nvd.nist.gov/vuln/detail/CVE-2026-64579

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.