CVE-2025-38097: espintcp: remove encap socket caching to avoid reference leak
In the Linux kernel, the following vulnerability has been resolved:
espintcp: remove encap socket caching to avoid reference leak
The current scheme for caching the encap socket can lead to reference
leaks when we try to delete the netns.
The reference chain is: xfrm_state -> enacp_sk -> netns
Since the encap socket is a userspace socket, it holds a reference on
the netns. If we delete the espintcp state (through flush or
individual delete) before removing the netns, the reference on the
socket is dropped and the netns is correctly deleted. Otherwise, the
netns may not be reachable anymore (if all processes within the ns
have terminated), so we cannot delete the xfrm state to drop its
reference on the socket.
This patch results in a small (~2% in my tests) performance
regression.
A GC-type mechanism could be added for the socket cache, to clear
references if the state hasn't been used "recently", but it's a lot
more complex than just not caching the socket.
Security readout for executives and security teams
Plain-English summary
This Linux kernel bug can prevent deleted network namespaces from being fully released because an ESP-in-TCP socket remains referenced. On systems repeatedly creating and removing isolated network environments, retained resources could accumulate. The assigned CVSS score is 7.8, but the sources do not demonstrate remote exploitation or real-world attacks.
Executive priority
Treat this as targeted high-priority maintenance for Linux hosts using ESP-in-TCP with frequent network-namespace removal. Expedite vendor-supported updates on matching systems. Fleets without that feature combination are less likely exposed, and available evidence does not support treating this as an active internet-wide emergency.
Technical view
ESP-in-TCP caches a userspace encapsulation socket in an XFRM state. The socket references its network namespace, forming xfrm_state to encap_sk to netns. If namespace removal precedes XFRM state deletion, the namespace may become unreachable while remaining referenced. Stable patches remove socket caching, with approximately 2% reported performance regression.
Likely exposure
Potential exposure is limited to affected Linux kernels using ESP-in-TCP, XFRM states, and network namespaces, particularly environments with frequent namespace removal. The bundle marks several releases from 5.6 through 6.15 as affected, but lacks a clear distributor-specific version matrix. Confirm backport status with the operating-system vendor.
Exploitation context
The source bundle contains no evidence of active exploitation or a public exploit, and KEV is false. The CVSS vector describes local, low-complexity, low-privilege access without user interaction. However, the provided technical narrative does not establish a practical attack path beyond triggering the reference-leak condition.
Researcher notes
The CVSS vector assigns high confidentiality, integrity, and availability impacts, while the kernel description principally documents reference retention and namespace cleanup failure. The supplied evidence does not explain confidentiality or integrity loss. Fixed commits remove socket caching and accept a small performance cost. Additional distributor analysis is needed to reconcile impact and exact affected-version boundaries.
Mitigation direction
Apply a vendor-supported kernel update incorporating the applicable Linux stable fix.
Confirm affected-version and backport status through the operating-system distributor.
Where feasible, delete ESP-in-TCP XFRM states before removing their network namespaces.
Validation and detection
Inventory kernel versions on systems using ESP-in-TCP and network namespaces.
Confirm deployed kernels include the applicable stable fix or distributor backport.
Test namespace teardown and resource recovery safely in staging after remediation.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-38097 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
1ADP providers
7Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.