Linux kernel (net/xfrm): Flushing xfrm states during namespace cleanup re-arms the NAT-keepalive delayed work after it

Impact

Flushing xfrm states during namespace cleanup re-arms the NAT-keepalive delayed work after it was cancelled, so the work can fire against a struct net that has already been freed and reallocated - a use-after-free in the host kernel driven by ordinary namespace teardown.

Who can reach it

Any workload that creates a network namespace, installs SAs with NAT keepalive, and exits - i.e. every pod delete on a node where containers hold CAP_NET_ADMIN in a user namespace and run IPsec. The race is between cleanup_net rounds, so high netns churn (normal Kubernetes behaviour) widens the window. Conditional on NAT-T keepalives being in use.

What to do

Boot a kernel carrying the linked stable commits. Interim: drop CAP_NET_ADMIN from tenant containers so per-tenant SAs with keepalives cannot be created, or disable NAT keepalives where NAT is not in the path.

References