Database/Kernel, userspace & hypervisor
Linux kernel (net/xfrm): Setting a per-socket IPsec policy reset the socket's destination cache non-atomically while
Impact
Setting a per-socket IPsec policy reset the socket's destination cache non-atomically while the UDP transmit fast path resets the same field with an atomic exchange. Racing the two drops the single reference twice and frees the xfrm destination bundle while it is still in use. The upstream report shows a KASAN use-after-free write with a working exploit binary in the trace - a freed-object write primitive in the kernel, which on a shared GPU node means a tenant escaping its container onto the host.
Who can reach it
The commit states it plainly: reachable by an unprivileged user via a user+network namespace. Concretely, a tenant process creates a connected UDP socket, loops IP_XFRM_POLICY setsockopt against a concurrent sendmsg, and wins the race. No CAP_NET_ADMIN on the host, no fabric access, no device node - just an unprivileged process inside a container with unprivileged user namespaces enabled, which is the default on most container hosts.
What to do
Boot a kernel carrying the fix commits below (the version list in the record marks introduction points, not fixes - match by commit). Interim control: disable unprivileged user namespaces on shared nodes (kernel.unprivileged_userns_clone=0 or user.max_user_namespaces=0 for tenant cgroups), which removes the stated reachability path.
References
Related entries
- Linux kernel (net/xfrm): Xfrm_selector_match() compared selectors without checking that the selector family matches theCVE-2026-72450 · Linux kernel (net/xfrm)High
- Linux kernel (net/xfrm): Several error paths in the ESP-in-TCP receive code return without freeing the skb, soCVE-2025-38057 · Linux kernel (net/xfrm)High
- Linux kernel (net/xfrm): Xfrm_alloc_spi could hand out an SPI that is already in use by another inbound SA, because theCVE-2025-39797 · Linux kernel (net/xfrm)High
- Linux kernel (net/xfrm): One crafted inner IPv4 header (tot_len = 0) inside an IPTFS payload puts the receive path intoCVE-2026-31472 · Linux kernel (net/xfrm)High
- Linux kernel (net/xfrm): A peer that mixes zero-copy-eligible and copy-path IPTFS fragments in one datagram makesCVE-2026-31517 · Linux kernel (net/xfrm)High
- Linux kernel (net/xfrm): A qdisc that reuses skbCVE-2023-53500 · Linux kernel (net/xfrm)High
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.