Linux kernel (net/xfrm): SA lookup can observe the new hash mask before the new bucket array is published, so it

Impact

SA lookup can observe the new hash mask before the new bucket array is published, so it indexes past the end of the old table - an out-of-bounds read in the code path that decides which security association handles a packet. Besides the read, a lookup that lands in garbage can miss or mismatch the SA for in-flight traffic.

Who can reach it

Driven by packet processing on any IPsec-enabled node while the state table is resized. The resize happens as SAs are added, i.e. as tenants' IPsec tunnels come and go, so the race window opens during normal churn on a per-tenant encrypted overlay. Anyone who can cause SA creation (the IKE daemon, or a container with CAP_NET_ADMIN in its netns) can force the rehash on demand.

What to do

Boot a kernel carrying the linked stable commits. Interim: pre-size the xfrm state hash where possible and avoid rapid SA churn; drop CAP_NET_ADMIN from tenant containers so they cannot force rehashing.

References