CVE-2025-39797

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: Duplicate SPI Handling<br /> <br /> The issue originates when Strongswan initiates an XFRM_MSG_ALLOCSPI<br /> Netlink message, which triggers the kernel function xfrm_alloc_spi().<br /> This function is expected to ensure uniqueness of the Security Parameter<br /> Index (SPI) for inbound Security Associations (SAs). However, it can<br /> return success even when the requested SPI is already in use, leading<br /> to duplicate SPIs assigned to multiple inbound SAs, differentiated<br /> only by their destination addresses.<br /> <br /> This behavior causes inconsistencies during SPI lookups for inbound packets.<br /> Since the lookup may return an arbitrary SA among those with the same SPI,<br /> packet processing can fail, resulting in packet drops.<br /> <br /> According to RFC 4301 section 4.4.2 , for inbound processing a unicast SA<br /> is uniquely identified by the SPI and optionally protocol.<br /> <br /> Reproducing the Issue Reliably:<br /> To consistently reproduce the problem, restrict the available SPI range in<br /> charon.conf : spi_min = 0x10000000 spi_max = 0x10000002<br /> This limits the system to only 2 usable SPI values.<br /> Next, create more than 2 Child SA. each using unique pair of src/dst address.<br /> As soon as the 3rd Child SA is initiated, it will be assigned a duplicate<br /> SPI, since the SPI pool is already exhausted.<br /> With a narrow SPI range, the issue is consistently reproducible.<br /> With a broader/default range, it becomes rare and unpredictable.<br /> <br /> Current implementation:<br /> xfrm_spi_hash() lookup function computes hash using daddr, proto, and family.<br /> So if two SAs have the same SPI but different destination addresses, then<br /> they will:<br /> a. Hash into different buckets<br /> b. Be stored in different linked lists (byspi + h)<br /> c. Not be seen in the same hlist_for_each_entry_rcu() iteration.<br /> As a result, the lookup will result in NULL and kernel allows that Duplicate SPI<br /> <br /> Proposed Change:<br /> xfrm_state_lookup_spi_proto() does a truly global search - across all states,<br /> regardless of hash bucket and matches SPI and proto.