Database/Kernel, userspace & hypervisor
Linux kernel (net/xfrm): SPI 0 means 'no SPI assigned', but the duplicate-SPI rework started creating states with SPI 0
Impact
SPI 0 means 'no SPI assigned', but the duplicate-SPI rework started creating states with SPI 0 and putting them on the byspi list. Deleting such a state never removes it from that list, so the next walk of the list touches freed memory - a use-after-free in the security-association table that also leaves phantom entries in SA lookup.
Who can reach it
Reached through the normal IKE control path: XFRM_MSG_ALLOCSPI / SA creation over xfrm netlink, available to the node's IKE daemon (strongSwan, libreswan) and to any process with CAP_NET_ADMIN in its network namespace - which includes containers granted NET_ADMIN. On a node with churning child SAs the condition arises without an attacker.
What to do
Update to 6.6.109 / 6.12.50 / 6.16.10 or later, or a kernel carrying the linked stable commits. Interim: drop CAP_NET_ADMIN from tenant containers so only the node's IKE daemon can create SAs.
References
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.