Linux kernel (net/xfrm): Xfrm_alloc_spi could hand out an SPI that is already in use by another inbound SA, because the

Impact

Xfrm_alloc_spi could hand out an SPI that is already in use by another inbound SA, because the uniqueness check hashed on destination address as well as SPI. Two live inbound SAs then share an SPI and inbound lookup returns an arbitrary one of them, so ESP packets are matched against the wrong security association - wrong keys, wrong policy, wrong peer attribution. This is an encryption-attribution break with no memory corruption involved: traffic is decrypted (or dropped) under an SA that belongs to someone else.

Who can reach it

Reached through XFRM_MSG_ALLOCSPI, issued by the node's IKE daemon (strongSwan/libreswan) or by any process with CAP_NET_ADMIN in its network namespace, which includes containers granted NET_ADMIN. It is deterministic when the configured SPI range is narrow (charon spi_min/spi_max) and probabilistic but real on any node carrying many child SAs - the shape of a per-tenant IPsec overlay where each tenant pair gets its own SA.

What to do

Boot a kernel carrying the linked stable commits, and pair it with the follow-up fix for SPI 0 (CVE-2025-39965) which the same change introduced. Interim: widen the IKE daemon's SPI range so collisions are far less likely, and audit for duplicate inbound SPIs with 'ip xfrm state' on nodes running many SAs.

References