Bug 2403546 (CVE-2025-39965)

Summary: CVE-2025-39965 kernel: xfrm: xfrm_alloc_spi shouldn't use 0 as SPI
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedKeywords: Security
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A use-after-free flaw was found in the Linux kernel IPsec subsystem in the way Security Parameter Indexes (SPI) are allocated and tracked. States created with an SPI value of 0 were added to the per-SPI list, and later deletion paths did not remove them from that list. A local user with the ability to configure IPsec could use this flaw to crash the system, resulting in a denial of service.
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2025-10-13 14:01:36 UTC
In the Linux kernel, the following vulnerability has been resolved:

xfrm: xfrm_alloc_spi shouldn't use 0 as SPI

x->id.spi == 0 means "no SPI assigned", but since commit
94f39804d891 ("xfrm: Duplicate SPI Handling"), we now create states
and add them to the byspi list with this value.

__xfrm_state_delete doesn't remove those states from the byspi list,
since they shouldn't be there, and this shows up as a UAF the next
time we go through the byspi list.