EUVD-2026-93169
GHSA-5mfq-x364-3h2r
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessConnect to IPv6 TCP listener on XFRM host
-
DeliveryForce low-MTU XFRM tunnel route selection
-
ExploitSYN-ACK PMTU/error path runs with request_sock attached
-
ExecutionKernel miscasts mini-socket, reads past allocation
-
ImpactKernel oops or memory disclosure
Vulnerability Assessment
| Exploitation Conditions | Exploitation requires a very specific deployment: the host must have IPv6 IPsec/XFRM transformation routes configured, an IPv6 TCP service that generates SYN-ACKs, and route re-selection that picks an XFRM tunnel route with a lower MTU so the local PMTU (xfrm6_local_rxpmtu) or local error (xfrm6_local_error) path is reached while the skb is still owned by a TCP_NEW_SYN_RECV request_sock rather than a full socket. Limiting factors: XFRM/IPsec is a non-default configuration requiring administrative setup, the defect only manifests during the SYN-ACK/request-sock window (a timing/race edge case), and it is confined to the IPv6 output path - hosts without IPv6 XFRM tunnels are not affected. These preconditions substantially narrow the realistic attack surface below what the raw 7.8 score implies. |
| Impact | Signals point consistently toward LOW real-world priority despite the 7.8 'High' CVSS. EPSS is 0.18% (7th percentile), the CVE is NOT in CISA KEV, and no public exploit code is identified - so exploitation status is 'no public exploit identified at time of analysis.' The input CVSS vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) appears to be the Linux kernel project's standard auto-assigned scoring rather than a bug-specific analysis, and it conflicts with the description: the C:H/I:H/A:H full-triad impact is questionable for what is fundamentally a read-beyond-allocation of a request_sock (an out-of-bounds READ), which realistically yields a kernel crash/oops (availability) or possible info leak (confidentiality) but NOT integrity compromise - verify impact with vendor. Likewise AC:L understates the trigger: it requires a narrow sequence (IPv6 TCP listener + XFRM/IPsec tunnel route selection with a lower MTU hitting the local PMTU/error path while a TCP_NEW_SYN_RECV mini-socket is attached), which is an edge/race condition, not a reliable primitive. No SSVC record is provided. Net: a legitimately fixed memory-safety defect that should be patched via normal kernel update cadence, but not an emergency given low EPSS, no KEV, no POC, and demanding preconditions. |
| Exploit ScenarioDerived | On a Linux host configured with IPv6 IPsec/XFRM, an attacker initiates TCP connections to an IPv6 listener so the kernel emits SYN-ACKs while a TCP_NEW_SYN_RECV request_sock is attached to the skb; if rerouting selects an XFRM tunnel route with a lower MTU, the local PMTU/error callback miscasts the request socket as a full IPv6 socket and reads past its allocation, typically crashing the kernel (DoS) or potentially leaking adjacent memory. No public proof-of-concept is identified at time of analysis, and reliable triggering depends on winning the routing/MTU timing, so practical exploitation is difficult. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 07, 2026
Out-of-bounds memory reads in the Linux kernel's IPv6 XFRM local path allow a locally authenticated attacker who can trigger specific XFRM/IPsec routing conditions to miscast a TCP request socket as a full IPv6 socket, disclosing kernel heap memory. The flaw affects Linux 3.2 and later and is triggered only when IPv6 XFRM tunnel routes are configured, an IPv6 TCP service emits SYN-ACKs, and rerouting selects a lower-MTU tunnel so the local PMTU or local error callback runs while the skb is still owned by a TCP_NEW_SYN_RECV request_sock. It requires local access with low privileges (CVSS vector PR:L, AV:L); there is no public exploit identified at time of analysis, EPSS is low at 0.18% (7th percentile), and CISA KEV does not list it. Vendor patches are available, and the timing-dependent, non-default XFRM configuration substantially narrows the realistic attack surface below what the raw 7.8 score suggests.
RemediationAI
Apply the vendor-released kernel update containing the fix commit dd767856a36e00b631d65ebc4bb81b19915532d6 on the applicable stable branch - the confirmed patched versions are 5.10.271, 5.15.222, 6.1.189, 6.6.158, 6.12.112, 6.18.54, and 7.2.8 (with 7.3-rc4 for the development line), and the per-branch commit references are listed at https://git.kernel.org/stable/c/ and summarized via https://nvd.nist.gov/vuln/detail/CVE-2026-98241. Patch status is 'Patch available per vendor advisory' in the source data and the EUVD record confirms vendor patches for each branch, so upgrading to the matching stable release is the definitive fix. Because exploitation is gated on a non-default configuration and a narrow race, environments that cannot immediately patch can reduce exposure by removing or disabling IPv6 IPsec/XFRM transformation routes on hosts that do not strictly require them (side effect: loss of IPv6 VPN/tunnel connectivity), or by ensuring no IPv6 XFRM tunnel route advertises an MTU lower than the underlay path so the local PMTU/error callbacks are never entered with a request_sock attached (side effect: possible PMTU black-holing or fragmentation for tunneled IPv6 traffic, which must be validated against the deployment). Restricting local shell and unprivileged process access on multi-user hosts also raises the bar, since the vector requires local low-privileged access, but this is a compensating control rather than a substitute for the kernel update and does not close the underlying out-of-bounds read.
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
This is a defect in the Linux kernel's IPv6 IPsec/XFRM output error handling, specifically in the callbacks xfrm6_local_rxpmtu() and xfrm6_local_error(). These functions dereference skb->sk assuming it is always a full IPv6 socket, but during the SYN-ACK window a transmitted skb can still be owned by a TCP_NEW_SYN_RECV request_sock (a 'mini-socket' allocated for an incoming connection that has not yet completed the handshake). If rerouting after the SYN-ACK selects an IPv6 XFRM tunnel route with a lower MTU, the local PMTU or local error path can reach these callbacks with the request_sock still attached. Because request_sock is not a full inet_sock/ipv6_sock, the code reads inet_sock or ipv6_pinfo fields at offsets beyond the request_sock allocation, producing an out-of-bounds read. The fix resolves the true owner with skb_to_full_sk() in both callbacks and bails out when no full socket is attached, matching the surrounding XFRM IPv6 PMTU/error logic that already reasons about full sockets. No CWE was assigned in the source data; the defect class is an out-of-bounds read driven by a socket-type miscast, closely aligned to CWE-843 (Type Confusion) and CWE-125 (Out-of-bounds Read). The upstream commit is dd767856a36e00b631d65ebc4bb81b19915532d6, with stable backports referenced across multiple kernel branches.
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- and timing-dependent kernel path (XFRM IPsec plus a request_sock race) gives AC:H and PR:L; an out-of-bounds read yields info disclosure (C:H) and crash (A:H) but no integrity impact (I:N).
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
4DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
ipv6: xfrm: use full sockets in local error paths
xfrm6_local_rxpmtu() and xfrm6_local_error() dereference skb->sk as if it always pointed at a full IPv6 socket.
That is not guaranteed. TCP SYN-ACK skbs can be owned by a TCP_NEW_SYN_RECV request_sock while the output path itself is driven by the full listener. If rerouting selects an IPv6 XFRM tunnel route with a lower MTU, the local PMTU/error handling path can reach these callbacks with that mini-socket still attached to the skb.
The callbacks then miscast the request socket as a full inet/IPv6 socket and can read beyond the request_sock allocation when they access inet_sock or ipv6_pinfo state.
Resolve the owner with skb_to_full_sk() in both callbacks and bail out when no full socket is attached. This matches the surrounding XFRM IPv6 PMTU/error logic, which already reasons about full sockets with skb_to_full_sk().
Executive ViewAI
The Linux kernel (versions 3.2 and later) contains a high-severity vulnerability (CVE-2026-98241) that could allow a locally authenticated user to read sensitive kernel memory under specific IPv6 XFRM tunnel configurations. While exploitation requires local access and non-default routing setups, successful attacks could expose confidential data, potentially impacting system integrity and compliance. Leadership should prioritize patching affected systems to mitigate potential data leakage, especially in environments with IPsec/VPN deployments.
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