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

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