CVE-2025-38097

What it actually does

Caching of encap sockets in xfrm_state structures for espintcp creates a reference chain (xfrm_state -> encap_sk -> netns) that leaks netns references when states are deleted after netns teardown, because userspace sockets hold netns references that cannot be released once processes in the namespace have exited.

Why it matters to the business

In containerized or multi-tenant Linux environments this can cause stranded network namespaces that consume resources and block cleanup, leading to gradual resource exhaustion and operational instability; low urgency given absence from KEV and minimal EPSS.

How an attack unfolds

An attacker with the ability to create and delete xfrm espintcp states (for example via crafted IPsec policies) times state deletion relative to netns removal so that the socket reference prevents netns destruction, resulting in a persistent leak; no named threat actors are known to weaponize this specific issue.

How to fix it

Upgrade the Linux kernel to a version containing commit e4cde54b46a87231c77256a633be1bef62687d69; for affected Chainguard and Wolfi packages update docker-credential-acr-env to 0.7.0-r21 or later.

How to confirm the fix worked

Confirm the patch is present by checking kernel git history for e4cde54b46a87231c77256a633be1bef62687d69 or by verifying that encap socket caching has been removed from espintcp state handling; test netns deletion after xfrm state flush.

Typical attack path

1. Obtain privileges sufficient to manage xfrm states or IPsec configuration
2. Create espintcp xfrm states that cache encap sockets
3. Trigger netns deletion while states remain
4. Observe inability to release the netns due to the held socket reference

How to detect it

Examine kernel logs for repeated netns deletion failures or reference count warnings around xfrm and espintcp; review audit trails of xfrm state additions and deletions correlated with netns lifecycle events.

What your security team should do

• Prioritize kernel updates on systems that use IPsec with espintcp in containers or network namespaces
• Monitor for kernel updates in stable trees and apply within normal patch windows given low EPSS
• Review IPsec and xfrm usage to determine exposure scope