EUVD-2026-38705
GHSA-9xww-vmqg-jh2q
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Local PR:L user; AC:H due to the send-timing race to keep a partial send in flight; OOB read yields C:H and possible crash A:H, but no integrity write so I:N.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Lifecycle Timeline
5DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
xfrm: espintcp: do not reuse an in-progress partial send
espintcp keeps a single in-flight transmit in ctx->partial. Before building a new sk_msg, espintcp_sendmsg() first tries to flush that state through espintcp_push_msgs().
For blocking callers, espintcp_push_msgs() may return success even when the previous partial send is still pending. espintcp_sendmsg() would then reinitialize emsg->skmsg and reuse ctx->partial while the old transfer still owns that state.
Do not rebuild the send message when ctx->partial is still in progress. If espintcp_push_msgs() returns with emsg->len still set, fail the new send instead of overwriting the live partial state.
This is a memory-safety fix: reusing the live partial-send state can leave a stale offset attached to a new sk_msg and lead to an out-of- bounds read in the send path.
tcp_sendmsg_locked() already handles waiting for send buffer memory, so the fix here is just to preserve espintcp's one-message-at-a-time transmit state.
AnalysisAI
Out-of-bounds read in the Linux kernel's xfrm espintcp (ESP-in-TCP IPsec encapsulation) send path allows a local user with a socket using espintcp to corrupt the one-message-at-a-time transmit state, leading to memory disclosure or a crash. The flaw stems from espintcp_sendmsg() reinitializing emsg->skmsg and reusing ctx->partial while a previous partial send is still in flight, attaching a stale offset to a fresh sk_msg. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Exploitation requires a local user able to open and drive an espintcp socket on a kernel where ESP-in-TCP (RFC 8229) IPsec encapsulation is configured and in use - this is the specific feature that must be enabled; the bug is not reachable on systems using UDP-encapsulated or native ESP. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | Signals are consistent and point to a real but low-urgency, locally-scoped memory-safety bug. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | A local unprivileged user on a host that uses ESP-in-TCP IPsec opens an espintcp socket and issues blocking sends timed so a partial transmit is still pending when a new sendmsg() is invoked. The kernel rebuilds the send message over the live partial state, and the stale offset drives an out-of-bounds read in the send path, leaking adjacent kernel/socket memory or crashing the system. … |
| Remediation | Apply the vendor-released kernel update for your stable series - upgrade to 5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.94, 6.18.36, 7.0.13, or mainline 7.1 (or later) as appropriate to your branch; consume these via your distribution's patched kernel package and reboot. … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours: Inventory systems deploying xfrm espintcp (consult infrastructure documentation for IPsec configurations). …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
Same weakness CWE-787 – Out-of-bounds Write
View allSame technique Memory Corruption
View allShare
External POC / Exploit Code
Leaving vuln.today