Linux kernel (net/xfrm): Tearing down an IPTFS security association cancels its hrtimers while holding the very locks

CVSS 6.5CVE-2026-53197Kernel, userspace & hypervisorcurated

Impact

Tearing down an IPTFS security association cancels its hrtimers while holding the very locks those timer callbacks take. On SMP that closes an ABBA cycle - one CPU spins on the softirq expiry lock while the softirq holding it waits for the spinlock the canceller owns. Neither side ever progresses, so a lock held on the IPsec datapath is never released and packet processing on the node stops. Every tenant on that host loses fabric connectivity until it is power-cycled.

Who can reach it

Requires the ability to delete an IPTFS xfrm state while its output or drop timer is firing - host root, or a tenant container holding CAP_NET_ADMIN in its own user+network namespace, which can create and delete IPTFS SAs in a loop while pushing traffic through them to keep the timers hot. Conditional on IP-TFS mode being available. Found by source-code audit rather than a fuzzer, so treat the deadlock as reachable but not yet weaponised in public.

What to do

Boot a kernel carrying the fix commits below (no fixed stable version published). Interim control: remove CAP_NET_ADMIN from tenant user namespaces so tenants cannot churn IPTFS SAs, or blacklist xfrm_iptfs where IP-TFS is not deliberately in use.

References

https://git.kernel.org/stable/c/a13ca53e47e500854a3b9ec18b5dc83acfec863e https://git.kernel.org/stable/c/822b98d354e63e8249e85473c5f3c519f3c9cecc https://nvd.nist.gov/vuln/detail/CVE-2026-53197

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.