GPU VulnDB

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

CVE-2025-39965Kernel, userspace & hypervisorcurated

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.