Skip to main content

Linux Kernel EUVDEUVD-2026-38705

| CVE-2026-52935 HIGH
Out-of-bounds Write (CWE-787)
2026-06-24 Linux GHSA-9xww-vmqg-jh2q
Buffer Overflow Linux Memory Corruption Red Hat Suse
7.8
CVSS 3.1 · Vendor: Linux
Share

Severity by source

Vendor (Linux) PRIMARY
7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vuln.today AI
6.3 MEDIUM

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.

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H
4.0 AV:L/AC:H/AT:N/PR:L/UI:N/VC:H/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Red Hat
7.0 MEDIUM
qualitative

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jun 28, 2026 - 08:28 vuln.today
CVSS changed
Jun 28, 2026 - 08:22 NVD
7.8 (HIGH)
Patch available
Jun 24, 2026 - 09:16 EUVD
CVE Published
Jun 24, 2026 - 07:14 cve.org
HIGH 7.8
CVE Published
Jun 24, 2026 - 07:14 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.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. No public exploit is identified at time of analysis and EPSS is low (0.16%, 6th percentile), reflecting a niche, configuration-dependent attack surface rather than broad exploitability.

Technical ContextAI

The vulnerability lives in the kernel's XFRM (IPsec transformation) framework, specifically the espintcp module that encapsulates ESP packets inside a TCP stream (RFC 8229) for IKE/IPsec traversal of middleboxes. espintcp serializes outbound data through a single in-flight scatter-gather message buffer (ctx->partial / emsg->skmsg), enforcing one transmit at a time. For blocking senders, espintcp_push_msgs() could return success even though the prior partial send was not fully flushed (emsg->len still set); espintcp_sendmsg() then rebuilt the send message over the live state, leaving a stale byte offset bound to a new sk_msg. The fix refuses to rebuild while a partial send is in progress and fails the new send instead. Although the CWE is listed as N/A, the behavior is a classic out-of-bounds read (CWE-125) arising from use of stale length/offset state on a reused buffer.

RemediationAI

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. The corresponding upstream commits are available at git.kernel.org/stable (e.g. https://git.kernel.org/stable/c/6564e9c7af7e1dc7bfe7f3093b728abe484d7630). If immediate patching is not possible, the practical compensating control is to avoid using ESP-in-TCP encapsulation (espintcp) for IPsec - configure IKE/IPsec to use UDP encapsulation or native ESP instead, which removes the affected code path; the trade-off is loss of TCP-based NAT/firewall traversal where only TCP egress is permitted. Where espintcp cannot be disabled, restrict the ability of untrusted local users to create xfrm/espintcp sockets and monitor for unexpected kernel crashes.

Same weakness CWE-787 – Out-of-bounds Write

View all
CVE-2015-3113 CRITICAL POC
9.8
CVE-2011-2462 CRITICAL POC
9.8
CVE-2012-1889 HIGH POC
8.8
CVE-2010-3333 HIGH POC
7.8
CVE-2014-1761 HIGH POC
7.8
CVE-2009-3129 HIGH POC
7.8
CVE-2021-1732 HIGH POC
7.8
CVE-2013-3346 CRITICAL POC
9.8

Same technique Buffer Overflow

View all
CVE-2017-7269 CRITICAL POC
9.8
CVE-2015-5119 CRITICAL POC
9.8
CVE-2015-3113 CRITICAL POC
9.8
CVE-2011-2462 CRITICAL POC
9.8
CVE-2020-0796 CRITICAL POC
10.0
CVE-2019-11043 CRITICAL POC
9.8
CVE-2009-0927 HIGH POC
8.8
CVE-2012-1889 HIGH POC
8.8

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected

Share

EUVD-2026-38705 vulnerability details – vuln.today
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy