CVE-2026-52935: Linux Kernel Use-After-Free Vulnerability

CVE-2026-52935 Overview

CVE-2026-52935 is a memory-safety vulnerability in the Linux kernel's xfrm subsystem, specifically in the espintcp transport that carries IPsec ESP traffic over TCP. The flaw resides in espintcp_sendmsg(), which can reuse an in-progress partial send held in ctx->partial while the previous transfer still owns that state. When espintcp_push_msgs() returns success for blocking callers despite a pending partial send, the kernel reinitializes emsg->skmsg and overwrites live state. The result is a stale offset attached to a new sk_msg, leading to an out-of-bounds read in the send path.

Critical Impact
Local attackers using IPsec over TCP can trigger an out-of-bounds read in the kernel send path, risking information disclosure or kernel instability.

Affected Products

Linux kernel versions containing the espintcp transport in net/xfrm/
Distributions shipping affected stable kernel branches prior to the backported fixes
Systems using IPsec ESP encapsulated in TCP (espintcp)

Discovery Timeline

2026-06-24 - CVE-2026-52935 published to NVD
2026-06-24 - Last updated in NVD database

Technical Details for CVE-2026-52935

Vulnerability Analysis

The espintcp transport in the Linux kernel maintains a single in-flight transmit message in ctx->partial. Before assembling a new sk_msg, espintcp_sendmsg() calls espintcp_push_msgs() to flush any pending partial send. For blocking callers, that helper can return success while the previous partial send remains incomplete. The send path then proceeds to rebuild emsg->skmsg and reuse ctx->partial, even though the prior transfer still references it.

This violates espintcp's one-message-at-a-time transmit invariant. A stale offset from the prior transfer becomes attached to the freshly initialized sk_msg, and subsequent send operations read past the intended buffer boundary [CWE-125]. The fix preserves the invariant by failing the new send when emsg->len is still set, rather than overwriting live state.

Root Cause

The root cause is an incorrect assumption that a successful return from espintcp_push_msgs() means ctx->partial is free for reuse. In the blocking path, success can be reported while the partial send is still in progress, allowing concurrent ownership of the transmit state.

Attack Vector

Exploitation requires the ability to issue sendmsg() calls on an espintcp socket carrying IPsec ESP-in-TCP traffic. By driving the send path under conditions that produce a partial send, a local actor can cause the kernel to reuse the in-flight state and trigger the out-of-bounds read in the subsequent send. Refer to the upstream commits listed in the patch references for the exact code paths.

Detection Methods for CVE-2026-52935

Indicators of Compromise

Unexpected kernel warnings, KASAN reports, or oopses originating from espintcp_sendmsg() or espintcp_push_msgs() in net/xfrm/espintcp.c
Crashes or stalls on hosts terminating IPsec ESP-in-TCP tunnels under load
Process termination events tied to userspace processes performing sendmsg() on espintcp sockets

Detection Strategies

Enable KASAN on test kernels to surface out-of-bounds reads in the espintcp send path during fuzzing or regression testing
Monitor dmesg and the kernel ring buffer for stack traces referencing espintcp_sendmsg, espintcp_push_msgs, or sk_msg helpers
Correlate kernel fault events with IPsec policy and XFRM state changes in the audit logs

Monitoring Recommendations

Track installed kernel versions across the fleet and flag hosts running unpatched stable branches that include espintcp
Alert on repeated kernel panics or soft lockups on IPsec gateways and any system using ESP-in-TCP
Capture EDR telemetry on processes invoking IPsec-related syscalls to baseline normal espintcp usage

How to Mitigate CVE-2026-52935

Immediate Actions Required

Inventory all hosts using espintcp for IPsec ESP-in-TCP transport and prioritize them for patching
Apply the stable kernel updates referenced by the upstream commits and reboot affected systems
Restrict local access on IPsec endpoints to trusted operators until patches are deployed

Patch Information

The fix changes espintcp_sendmsg() so it does not rebuild the send message while ctx->partial is still in progress. If espintcp_push_msgs() returns with emsg->len still set, the new send fails instead of overwriting the live partial state. Waiting for send buffer memory is already handled by tcp_sendmsg_locked(). The patch is available across multiple stable branches:

Workarounds

Disable IPsec ESP-in-TCP encapsulation and revert to ESP over UDP or native ESP where the network path allows
Unload or blacklist the espintcp code path on systems that do not require TCP encapsulation
Limit which users can configure XFRM policy and open espintcp sockets through standard Linux capability controls