{"id":70044,"date":"2025-09-12T21:32:04","date_gmt":"2025-09-12T18:02:04","guid":{"rendered":"https:\/\/afaghhosting.net\/blog\/cve-2025-39797-xfrm-duplicate-spi-handling\/"},"modified":"2025-09-12T21:32:04","modified_gmt":"2025-09-12T18:02:04","slug":"cve-2025-39797-xfrm-duplicate-spi-handling","status":"publish","type":"post","link":"https:\/\/afaghhosting.net\/blog\/cve-2025-39797-xfrm-duplicate-spi-handling\/","title":{"rendered":"CVE-2025-39797 &#8211; xfrm: Duplicate SPI Handling"},"content":{"rendered":"<p><strong>CVE ID : <\/strong>CVE-2025-39797<br \/>\n<br \/>\n<strong>Published : <\/strong> Sept. 12, 2025, 4:15 p.m. | 29\u00a0minutes ago<br \/>\n<br \/>\n<strong>Description : <\/strong>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>xfrm: Duplicate SPI Handling<\/p>\n<p>The issue originates when Strongswan initiates an XFRM_MSG_ALLOCSPI<br \/>\nNetlink message, which triggers the kernel function xfrm_alloc_spi().<br \/>\nThis function is expected to ensure uniqueness of the Security Parameter<br \/>\nIndex (SPI) for inbound Security Associations (SAs). However, it can<br \/>\nreturn success even when the requested SPI is already in use, leading<br \/>\nto duplicate SPIs assigned to multiple inbound SAs, differentiated<br \/>\nonly by their destination addresses.<\/p>\n<p>This behavior causes inconsistencies during SPI lookups for inbound packets.<br \/>\nSince the lookup may return an arbitrary SA among those with the same SPI,<br \/>\npacket processing can fail, resulting in packet drops.<\/p>\n<p>According to RFC 4301 section 4.4.2 , for inbound processing a unicast SA<br \/>\nis uniquely identified by the SPI and optionally protocol.<\/p>\n<p>Reproducing the Issue Reliably:<br \/>\nTo consistently reproduce the problem, restrict the available SPI range in<br \/>\ncharon.conf : spi_min = 0x10000000 spi_max = 0x10000002<br \/>\nThis limits the system to only 2 usable SPI values.<br \/>\nNext, create more than 2 Child SA. each using unique pair of src\/dst address.<br \/>\nAs soon as the 3rd Child SA is initiated, it will be assigned a duplicate<br \/>\nSPI, since the SPI pool is already exhausted.<br \/>\nWith a narrow SPI range, the issue is consistently reproducible.<br \/>\nWith a broader\/default range, it becomes rare and unpredictable.<\/p>\n<p>Current implementation:<br \/>\nxfrm_spi_hash() lookup function computes hash using daddr, proto, and family.<br \/>\nSo if two SAs have the same SPI but different destination addresses, then<br \/>\nthey will:<br \/>\na. Hash into different buckets<br \/>\nb. Be stored in different linked lists (byspi + h)<br \/>\nc. Not be seen in the same hlist_for_each_entry_rcu() iteration.<br \/>\nAs a result, the lookup will result in NULL and kernel allows that Duplicate SPI<\/p>\n<p>Proposed Change:<br \/>\nxfrm_state_lookup_spi_proto() does a truly global search &#8211; across all states,<br \/>\nregardless of hash bucket and matches SPI and proto.<br \/>\n<br \/>\n<strong>Severity:<\/strong> 0.0 | NA<br \/>\n<br \/>\nVisit the link for more details, such as CVSS details, affected products, timeline, and more&#8230;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>CVE ID : CVE-2025-39797 Published : Sept. 12, 2025, 4:15 p.m. | 29\u00a0minutes ago 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 &hellip;<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-70044","post","type-post","status-publish","format-standard","hentry","category-vulnerability"],"_links":{"self":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/posts\/70044","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/comments?post=70044"}],"version-history":[{"count":0,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/posts\/70044\/revisions"}],"wp:attachment":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/media?parent=70044"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/categories?post=70044"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/tags?post=70044"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}