Linux kernel (net/xfrm): The rtnetlink changelink path for xfrm interfaces checked CAP_NET_ADMIN only against the

Impact

The rtnetlink changelink path for xfrm interfaces checked CAP_NET_ADMIN only against the namespace the request came from, not the namespace the interface actually lives in. A caller privileged in its own network namespace can therefore rewrite an xfrm interface belonging to a different namespace - changing its if_id, link, or the netns it is bound to. That reassigns which SA the interface's traffic is encrypted under, which is a direct route to another tenant's traffic being decrypted with the wrong key, steered to the wrong endpoint, or emitted in clear. The CNA marks the scope as changed, which is the right read.

Who can reach it

A tenant container that holds CAP_NET_ADMIN in its own user+network namespace and can see an xfrm interface whose link netns is elsewhere - the standard situation when the host or an orchestrator creates an xfrm device and moves it into a pod namespace, or shares one across namespaces. No fabric access, no host root, and no device node beyond an rtnetlink socket are needed.

What to do

Boot a kernel carrying the fix commits below (no fixed stable version published in the record). Interim control: stop granting CAP_NET_ADMIN in tenant user namespaces; do not create xfrm interfaces in one namespace and expose them into another; keep the IPsec control plane entirely on the host side of the boundary.

References