EUVD-2026-93157
GHSA-cfrr-f5xv-fcq4
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGain local access to IPsec-configured host
-
DeliveryTrigger inbound xfrm packet processing
-
ExploitRace concurrent xfrm_state deletion
-
ExecutionDereference freed state in xfrm_input
-
ImpactCorrupt kernel memory / crash
Vulnerability Assessment
| Exploitation Conditions | The host must have IPsec/xfrm active with VTI tunnels or XFRM interfaces configured - the vulnerable secpath_reset() calls only occur in the VTI receive path, the XFRM-interface cross-netns path, or the XFRM_MAX_DEPTH error path. Exploitation additionally requires winning a race: the last xfrm_state reference must be dropped via secpath_reset while the state is concurrently deleted and before xfrm_input() finishes dereferencing it. Limiting factors: this is non-default (plain hosts without IPsec/VTI/XFRM interfaces are unaffected), success depends on precise timing of concurrent state teardown (not a deterministic single-shot trigger), and the input CVSS implies local/low-privilege access rather than unauthenticated remote exploitation. |
| Impact | This is a use-after-free in the Linux kernel's IPsec/xfrm receive path (xfrm_input), where secpath_reset() in VTI, XFRM-interface, or XFRM_MAX_DEPTH paths can drop the last reference to a concurrently-deleted xfrm_state that xfrm_input() then still dereferences. The input CVSS of 7.8 (AV:L/AC:L/PR:L/UI:N/C:H/I:H/A:H) is the generic score the kernel CNA auto-applies to most memory-safety fixes and likely overstates real-world ease: exploitation hinges on winning a race between packet receive processing and state teardown, which is not reflected in the AC:L rating. The corroborating signals point to low practical priority - EPSS is 0.21% (10th percentile), there is no CISA KEV listing, and no public exploit is identified. Signals are therefore consistent (low EPSS, no KEV, no POC) rather than conflicting, with the one caveat that the vendor CVSS AC:L is optimistic for a concurrency bug. Note also a tagging discrepancy: the input labels this 'Information Disclosure,' but the root cause is a use-after-free whose most likely outcome is a crash/DoS (availability) with possible info-leak or escalation - treat the C/I/A breakdown as uncertain. |
| Exploit ScenarioDerived | On a host configured with IPsec using VTI or XFRM interfaces, a local attacker (or one able to influence IPsec state lifecycle) induces deletion of an xfrm_state at the moment inbound ESP/AH packets are being processed, causing xfrm_input() to dereference the freed state when selecting transport_finish() or reporting the drop-callback protocol. Winning this race corrupts kernel memory, most reliably producing a crash and potentially enabling info disclosure or privilege escalation. No public exploit identified at time of analysis; reliable triggering requires precise timing against the concurrent state-deletion window. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 07, 2026
Use-after-free in the Linux kernel's IPsec/xfrm receive path (xfrm_input) can be triggered by a local attacker with low privileges on hosts that run IPsec with VTI tunnels or XFRM interfaces configured. The receive callbacks for VTI and XFRM interfaces - as well as the XFRM_MAX_DEPTH error path - call secpath_reset(), which can drop the last reference to an xfrm_state that xfrm_input() subsequently dereferences when selecting transport_finish() or reporting the drop-callback protocol; if that state is concurrently deleted, the freed object is accessed, yielding memory corruption with high confidentiality and integrity impact. Successful exploitation requires winning a race between secpath_reset() and concurrent xfrm_state teardown, so the assessed vector is CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H (note the high attack-complexity, which differs from the NVD-published AC:L value); EPSS is low at 0.21% (10th percentile), there is no KEV listing, and no public exploit identified at time of analysis.
RemediationAI
Vendor-released patch: upgrade to Linux 6.12.112, 6.18.54, 7.2.8, or 7.3-rc4 (or later) as applicable to your branch; the upstream stable fixes are commits 3cf5cdecd99c9c186a5ea518d93bbf3045b6e3aa, 35de97850987b3d022ed17df5b2577242e746daf, 148db154066b066616b82c12d373e786eba1f96a, and 537a5ae18b2be70f8eb0aca843682e81a69aab91, and the base commit is df3893c176e9b0bb39b28ab5ec8113fa20ad1ee0, with details at https://git.kernel.org/stable/c/3cf5cdecd99c9c186a5ea518d93bbf3045b6e3aa and https://nvd.nist.gov/vuln/detail/CVE-2026-98229. Where the kernel cannot be updated, compensating controls must target the specific vulnerable call sites: avoid configuring VTI tunnels and XFRM interfaces on the host (plain IPsec transport/tunnel mode without a VTI or XFRM interface does not reach the VTI or XFRM-interface secpath_reset() paths), understanding that this reduces XFRM/VTI-based routing and netns-crossing flexibility but is the most direct mitigation; if VTI or XFRM interfaces are required, confine them to a single network namespace so the cross-network-namespace secpath_reset() path is not exercised (this does not eliminate the VTI-path and XFRM_MAX_DEPTH resets); and reduce race likelihood by avoiding concurrent aggressive xfrm_state teardown/flush churn (for example, frequent automated SA rekeying or teardown scripts) on hosts handling untrusted traffic, though this is a probabilistic reduction rather than a fix. Because exploitation is local and low-privilege, restrict untrusted local users and unprivileged network-namespace creation (e.g., disable unprivileged user/network namespaces) as defense in depth, accepting that this may break container or sandbox workloads. Given EPSS 0.21% and no KEV listing, prioritization should follow normal patching cadence for systems running IPsec with VTI/XFRM interfaces.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The affected code is the kernel's IPsec transform (xfrm) receive pipeline. In xfrm_input(), the current xfrm_state is stored in the skb's secpath while receive-side processing continues. Receive callback users - the VTI driver and the XFRM interface driver - can reset the secpath mid-processing: VTI resets it before checking whether the packet crosses network namespaces, and the XFRM interface path resets it only for cross-network-namespace packets. The XFRM_MAX_DEPTH error path can also reset the secpath before the final drop callback reports the current state's protocol. If secpath_reset() releases the last reference on the state while that state is being deleted concurrently, xfrm_input() still dereferences the freed xfrm_state when choosing transport_finish() or when the drop callback reports the state's protocol - the root-cause class consistent with the independent assessment is a use-after-free (CWE-416) driven by a reference-lifetime/race condition rather than a simple missing check. The upstream fix saves the state protocol on the stack while the state is still valid and reuses the already-saved address family for transport_finish(); because a larval XFRM_STATE_ACQ state has no type, nexthdr is retained as its protocol, preserving the existing drop-path fallback while eliminating the post-reset dereferences without adding an extra state reference to every received packet.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Config-dependent (IPsec/VTI/XFRM) and timing-sensitive race → AC:H and local-privilege trigger PR:L/AV:L; kernel UAF retains H/H/H impact pending confirmation.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
4DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
xfrm: save input state data before secpath resets
xfrm_input() stores the current xfrm_state in the skb secpath while it continues receive-side processing. Some input paths can reset that secpath before xfrm_input() has finished dereferencing the state.
Receive callback users such as VTI and XFRM interfaces can reset the secpath. The VTI receive path does so before checking whether the packet crosses network namespaces, while the XFRM interface path does so only for cross-network-namespace packets. The XFRM_MAX_DEPTH error path can also reset the secpath before the final drop callback reports the current state's protocol.
If secpath_reset() drops the last state reference while the state is concurrently deleted, xfrm_input() can still dereference the freed state when selecting transport_finish() or reporting the drop callback protocol.
Save the state protocol on the stack while the state is still valid, and use the already saved address family for transport_finish(). A larval XFRM_STATE_ACQ state has no type, so retain nexthdr as its protocol. This preserves the existing drop-path fallback while avoiding the post-reset state dereferences without adding an extra state reference to every received packet.
Executive ViewAI
Linux hosts that terminate IPsec traffic through VTI tunnels or XFRM interfaces - including VPN gateways, cloud networking nodes, and multi-tenant container hosts - are affected by CVE-2026-98229, a high-severity use-after-free in the kernel's xfrm receive path that a low-privileged local user could exploit to corrupt memory and potentially read or alter protected data. Because these kernels underpin the isolation boundaries that segmented networks and tenant workloads rely on, a successful attack could erode the trust assumptions those platforms are built around. Exploitation requires winning a narrow race condition against concurrent IPsec state teardown and no public exploit identified at time of analysis, so this is a scheduled patch item rather than an emergency - but the affected estate is infrastructure-critical and remediation should not drift.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Exploit-DB