CVE-2025-39797: Linux kernel · xfrm: Duplicate SPI Handling
Affects Linux kernelSource CVE Database V5
Not known to be exploited · fixed in fb58962aa3b9359988c7b5b15a971fd9ad5b0ecd : update Linux kernel when convenient.
Data as of 30 Oct 2026, 12:49 UTC
Rated by Threat Radar · No CVSS score from NVD or the CNA
Thin evidence
One scorer or none- Patch
- Available – fixed in fb58962aa3b9359988c7b5b15a971fd9ad5b0ecd, c67d4e7a8f90fb6361ca89d4d5c9a28f4e935e47, 94f39804d891cffe4ce17737d295f3b195bc7299 +3
Exploitation evidence
Disclosed: evidence found.
CVE published 12 Sep 2025
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 30 Oct 2026.
What to do
Upgrade to a fixed release listed under Affected software.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
Description
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.
References
- git.kernel.org/stable/c/fb58962aa3b9359988c7b5b15a971fd9ad5b0ecd (opens in a new tab)
- git.kernel.org/stable/c/3d8090bb53424432fa788fe9a49e8ceca74f0544 (opens in a new tab)
- git.kernel.org/stable/c/2fc5b54368a1bf1d2d74b4d3b8eea5309a653e38 (opens in a new tab)
- git.kernel.org/stable/c/c67d4e7a8f90fb6361ca89d4d5c9a28f4e935e47 (opens in a new tab)
- git.kernel.org/stable/c/29e9158f91f99057dbd35db5e8674d93b38549fe (opens in a new tab)
- git.kernel.org/stable/c/94f39804d891cffe4ce17737d295f3b195bc7299 (opens in a new tab)