VYPR
Unrated severityNVD Advisory· Published Dec 4, 2025· Updated Apr 15, 2026

CVE-2025-40215

CVE-2025-40215

Description

In the Linux kernel, the following vulnerability has been resolved:

xfrm: delete x->tunnel as we delete x

The ipcomp fallback tunnels currently get deleted (from the various lists and hashtables) as the last user state that needed that fallback is destroyed (not deleted). If a reference to that user state still exists, the fallback state will remain on the hashtables/lists, triggering the WARN in xfrm_state_fini. Because of those remaining references, the fix in commit f75a2804da39 ("xfrm: destroy xfrm_state synchronously on net exit path") is not complete.

We recently fixed one such situation in TCP due to defered freeing of skbs (commit 9b6412e6979f ("tcp: drop secpath at the same time as we currently drop dst")). This can also happen due to IP reassembly: skbs with a secpath remain on the reassembly queue until netns destruction. If we can't guarantee that the queues are flushed by the time xfrm_state_fini runs, there may still be references to a (user) xfrm_state, preventing the timely deletion of the corresponding fallback state.

Instead of chasing each instance of skbs holding a secpath one by one, this patch fixes the issue directly within xfrm, by deleting the fallback state as soon as the last user state depending on it has been deleted. Destruction will still happen when the final reference is dropped.

A separate lockdep class for the fallback state is required since we're going to lock x->tunnel while x is locked.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

In the Linux kernel, IPsec fallback tunnels can remain on hashtables after the last user state deletion, causing a WARN on netns exit; the fix deletes them synchronously with the user state.

Vulnerability

Overview

CVE-2025-40215 is a vulnerability in the Linux kernel's IPsec (xfrm) subsystem. The root cause is that IPcomp fallback tunnels (x->tunnel) are not deleted from the kernel's internal lists and hashtables when the corresponding user state is deleted; instead, they are only removed when the last reference to that user state is dropped. If a reference (e.g., from an skb with a secpath) persists, the fallback state remains on the hashtables, triggering a WARN in xfrm_state_fini during network namespace destruction [1][2].

Exploitation

Conditions

An attacker does not directly trigger this bug; it is a kernel resource management flaw. The issue manifests when skbs carrying a secpath are not freed promptly—for example, due to deferred TCP skb freeing (fixed in commit 9b6412e6979f) or IP reassembly queues that are not flushed before netns exit [1]. Any scenario where a reference to an xfrm state outlives the state's deletion can cause the fallback tunnel to linger.

Impact

If the fallback state remains on the hashtables, the kernel triggers a WARN (a kernel warning) during network namespace shutdown. While this does not directly lead to arbitrary code execution, it indicates a kernel state inconsistency that could be leveraged for denial-of-service (system crash or hang) or potentially other undefined behavior. The vulnerability undermines the completeness of a prior fix (commit f75a2804da39) that aimed to synchronously destroy xfrm states on netns exit [1].

Mitigation

The fix, applied in the Linux kernel stable tree, ensures that when a user xfrm state is deleted, its associated fallback tunnel (x->tunnel) is also deleted immediately from all lists and hashtables. A separate lockdep class is introduced for the fallback state to avoid lock ordering issues [1][2][3][4]. Users should apply the latest stable kernel updates containing this commit. No workaround is available; the issue is resolved only by patching.

AI Insight generated on May 19, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected products

2
  • Linux/Kernelinferred2 versions
    (expand)+ 1 more
    • (no CPE)
    • (no CPE)

Patches

6

Vulnerability mechanics

Generated on May 9, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

6

News mentions

0

No linked articles in our index yet.