CVE-2025-39797: Linux Kernel Privilege Escalation Vulnerability

CVE-2025-39797 Overview

CVE-2025-39797 is a flaw in the Linux kernel's XFRM (IP transformation framework) subsystem that permits duplicate Security Parameter Index (SPI) values to be assigned to inbound Security Associations (SAs). The xfrm_alloc_spi() function fails to enforce global SPI uniqueness because its hash lookup keys on destination address, protocol, and family. When Strongswan sends an XFRM_MSG_ALLOCSPI Netlink message, the kernel can return success for an SPI that is already in use by another SA with a different destination address. Inbound packet processing then becomes non-deterministic, causing lookups to return arbitrary SAs and dropping legitimate traffic.

Critical Impact
Duplicate SPI assignment corrupts inbound IPsec SA lookups, leading to packet drops and disruption of established IPsec tunnels on affected Linux kernels.

Affected Products

Linux kernel (multiple stable branches prior to the patched commits)
Distributions shipping the vulnerable net/xfrm subsystem
Systems running Strongswan or other IKE daemons that issue XFRM_MSG_ALLOCSPI requests

Discovery Timeline

2025-09-12 - CVE-2025-39797 published to the National Vulnerability Database
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-39797

Vulnerability Analysis

The vulnerability lives in the kernel's XFRM state management. RFC 4301 section 4.4.2 states that an inbound unicast SA is uniquely identified by its SPI and, optionally, the protocol. The kernel implementation instead relies on a hash computed from destination address, protocol, and family in xfrm_spi_hash(). Two SAs sharing the same SPI but bound to different destination addresses land in different hash buckets and separate byspi linked lists. The uniqueness check in xfrm_alloc_spi() therefore misses the collision and returns success.

On inbound packet processing, the SA lookup can match an arbitrary SA among the duplicates. When the returned SA does not correspond to the tunnel that produced the packet, decryption or replay-window checks fail and the packet is dropped. Reproducibility is deterministic when the SPI range is narrow. Setting spi_min = 0x10000000 and spi_max = 0x10000002 in charon.conf guarantees the third Child SA receives a duplicate SPI. With the default range the collision is rare but still possible.

Root Cause

The root cause is a bucketed uniqueness check where a global check is required. xfrm_alloc_spi() scans only the hash bucket produced by the destination-address-inclusive hash, so it cannot see SAs indexed under different destination addresses. The fix introduces xfrm_state_lookup_spi_proto(), which performs a truly global search across all XFRM states and matches on SPI and protocol only, aligning kernel behavior with RFC 4301.

Attack Vector

Exploitation requires local, authenticated access with the capability to install XFRM state, typically CAP_NET_ADMIN. An attacker or a misbehaving user-space IKE daemon can repeatedly issue XFRM_MSG_ALLOCSPI Netlink messages until SPI collisions occur, degrading availability of IPsec-protected traffic and potentially causing sustained tunnel disruption. The issue is a local availability and integrity problem rather than a remote code execution vector.

No verified public exploit code is available for CVE-2025-39797. The vulnerability mechanism is described in the upstream commit messages referenced in the Linux kernel stable tree.

Detection Methods for CVE-2025-39797

Indicators of Compromise

Unexpected inbound IPsec packet drops on kernels with multiple Child SAs sharing narrow SPI ranges.
ip xfrm state output showing two or more inbound SAs with identical SPI and protocol but different destination addresses.
Strongswan or charon logs reporting decryption failures or replay-window mismatches shortly after new Child SA installation.

Detection Strategies

Enumerate active XFRM states with ip -s xfrm state and script a check for duplicate (spi, proto) tuples across inbound SAs.
Correlate kernel XfrmInStateInvalid and XfrmInNoStates counters from /proc/net/xfrm_stat against SA rekeying events.
Monitor Netlink activity involving XFRM_MSG_ALLOCSPI from non-IKE processes as a signal of anomalous local activity.

Monitoring Recommendations

Alert on kernel version strings that predate the fix commits 29e9158, 2fc5b54, 3d8090b, 94f39804, and c67d4e7.
Track IPsec tunnel health metrics and packet-drop rates for gateways handling many concurrent Child SAs.
Log privileged CAP_NET_ADMIN usage and audit which processes hold it on IPsec endpoints.

How to Mitigate CVE-2025-39797

Immediate Actions Required

Update to a Linux kernel release that includes the XFRM duplicate SPI fix from the upstream stable branches.
Restrict CAP_NET_ADMIN to trusted IKE daemons only and remove ambient capabilities from unrelated services.
On gateways using Strongswan, avoid narrowing spi_min and spi_max in charon.conf beyond the number of concurrent Child SAs.

Patch Information

The fix replaces the bucketed SPI check with a global xfrm_state_lookup_spi_proto() search. Patched commits are available in the Linux stable tree: 29e9158, 2fc5b54, 3d8090b, 94f39804, and c67d4e7. Apply the vendor-supplied kernel package matching your distribution.

Workarounds

Widen the configured SPI range in charon.conf so that collisions become statistically unlikely until a patched kernel is deployed.
Reduce the number of concurrent Child SAs per gateway where operationally feasible.
Restart affected IPsec tunnels when duplicate-SPI symptoms appear to force re-allocation until the kernel is upgraded.

bash

# Configuration example: widen Strongswan SPI range to reduce collision probability
# /etc/strongswan.d/charon.conf
charon {
    spi_min = 0xc0000000
    spi_max = 0xcfffffff
}

# Verify running kernel version and check for duplicate inbound SPIs
uname -r
ip -o xfrm state | awk '/proto/ {print $0}' | grep -Eo 'spi 0x[0-9a-f]+' | sort | uniq -d