[SRU][J][PATCH 0/1] CVE-2025-39797

[Cengiz Can]

https://ubuntu.com/security/CVE-2025-39797

[ Impact ]

In the Linux kernel, the following vulnerability has been resolved:

xfrm: Duplicate SPI Handling

The issue originates when Strongswan initiates an XFRM_MSG_ALLOCSPI Netlink
message, which triggers the kernel function xfrm_alloc_spi(). This function is
expected to ensure uniqueness of the Security Parameter Index (SPI) for inbound
Security Associations (SAs). However, it can return success even when the
requested SPI is already in use, leading to duplicate SPIs assigned to multiple
inbound SAs, differentiated only by their destination addresses.

This behavior causes inconsistencies during SPI lookups for inbound packets.
Since the lookup may return an arbitrary SA among those with the same SPI,
packet processing can fail, resulting in packet drops.

According to RFC 4301 section 4.4.2 , for inbound processing a unicast SA is
uniquely identified by the SPI and optionally protocol.

Reproducing the Issue Reliably: To consistently reproduce the problem, restrict
the available SPI range in charon.conf : spi_min = 0x10000000 spi_max =
0x10000002 This limits the system to only 2 usable SPI values. Next, create
more than 2 Child SA. each using unique pair of src/dst address. As soon as the
3rd Child SA is initiated, it will be assigned a duplicate SPI, since the SPI
pool is already exhausted. With a narrow SPI range, the issue is consistently
reproducible. With a broader/default range, it becomes rare and unpredictable.

Current implementation: xfrm_spi_hash() lookup function computes hash using
daddr, proto, and family. So if two SAs have the same SPI but different
destination addresses, then they will: a. Hash into different buckets b. Be
stored in different linked lists (byspi + h) c. Not be seen in the same
hlist_for_each_entry_rcu() iteration. As a result, the lookup will result in
NULL and kernel allows that Duplicate SPI

Proposed Change: xfrm_state_lookup_spi_proto() does a truly global search -
across all states, regardless of hash bucket and matches SPI and proto.

[ Fix ]

jammy/linux: backported from 94f39804d891

The fix adds xfrm_state_lookup_spi_proto(), which performs a global search
across all SA states rather than relying on the per-bucket hash lookup, and
calls it from xfrm_alloc_spi() so that a requested or randomly chosen SPI that
already exists is rejected instead of being silently duplicated.

[ Test Plan ]

Build and boot tested.

[ Where Problems Could Occur ]

A regression would most likely affect systems that use IPsec/XFRM, such as
strongSwan or other IKE daemons terminating VPN tunnels or transport-mode SAs;
a flaw in the new global SPI search could cause valid SPI allocations to be
rejected, breaking tunnel establishment, or add lookup overhead on hosts that
maintain a large number of SAs. Systems that do not configure IPsec are not
affected by this change.

[ Other Info ]

Kybele flow-v12-16-g3521c8c5. Reference: 841378e1/v1