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

Related entries

• Linux kernel (net/xfrm): The error path of xfrm_input leaves the secpath entry pointing at poisoned memory, and theCVE-2024-43878 · Linux kernel (net/xfrm)High
• Linux kernel (net/xfrm): SA lookup can observe the new hash mask before the new bucket array is published, so itCVE-2024-57982 · Linux kernel (net/xfrm)High
• Linux kernel (net/xfrm): The guard that forbids changing a collect_md xfrm interface never fired, so a changelink putsCVE-2025-38500 · Linux kernel (net/xfrm)High
• Linux kernel (net/xfrm): If the task is preempted onto another CPU during SA lookup, a hit in the per-CPU state cacheCVE-2025-38675 · Linux kernel (net/xfrm)High
• Linux kernel (net/xfrm): SPI 0 means 'no SPI assigned', but the duplicate-SPI rework started creating states with SPI 0CVE-2025-39965 · Linux kernel (net/xfrm)High
• Linux kernel (net/xfrm): Closing an ESP-in-TCP socket cancels its transmit work item, but the write-space callback canCVE-2026-23239 · Linux kernel (net/xfrm)High