CVE-2026-52935

What it actually does

This Linux kernel flaw affects the XFRM ESP-in-TCP transmit path. The espintcp implementation tracks a single in-progress transmit operation in a partial-send state object. Under certain blocking send conditions, the kernel could treat a previous partial send as successfully flushed even though it was still pending, then rebuild and reuse the same state for a new sk_msg. That state reuse can leave stale offsets associated with the new message and cause an out-of-bounds read in the TCP send path. The most likely technical outcomes are kernel memory disclosure to the send path, kernel instability, or a crash if memory-safety instrumentation or fault handling detects the invalid access.

Why it matters to the business

Systems using Linux IPsec/XFRM with ESP-in-TCP encapsulation could experience VPN/IPsec instability, kernel crashes, or potential exposure of kernel memory contents under specific traffic and blocking-send conditions. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, has no public exploit maturity reported, and has a low EPSS score, so broad internet-scale exploitation is currently unlikely; however, kernel memory-safety flaws should still be prioritized on systems that terminate or generate IPsec-over-TCP traffic because failures can affect network availability and secure connectivity.

How an attack unfolds

An attacker would need a way to influence or generate traffic through the Linux kernel ESP-in-TCP transmit path, typically by operating as a local process, privileged network component, or authenticated peer in an environment where XFRM/IPsec ESP-in-TCP is configured. The attacker causes a send operation to enter a partial, in-progress state, then triggers another send while the previous partial state has not fully completed. In vulnerable kernels, espintcp_sendmsg() may reuse the live partial-send structure and associate stale offsets with a newly constructed sk_msg. When the kernel later processes that message through the TCP send path, it may read beyond the intended buffer bounds. Depending on memory layout, kernel configuration, and error handling, this can result in a crash, noisy KASAN-style diagnostics, or possible exposure of adjacent kernel memory.

How to fix it

Upgrade to a Linux kernel version that contains the upstream fix for the XFRM ESP-in-TCP partial-send state handling issue. If vendor-specific kernel packages are used, apply the security update from the Linux distribution or appliance vendor rather than attempting to patch individual source files manually. No exact fixed package versions were provided in the input, so remediation should be validated against vendor advisories for the deployed kernel branch. Where immediate patching is not possible, reduce exposure by disabling unused IPsec ESP-in-TCP functionality, limiting access to systems that can initiate or influence IPsec-over-TCP sessions, and monitoring for kernel instability on hosts that handle XFRM/IPsec traffic.

How to confirm the fix worked

Confirm the running kernel includes the fix that prevents espintcp_sendmsg() from rebuilding a send message while ctx->partial still has an active length. Validate by checking the installed kernel package against the relevant distribution advisory or by confirming the patched source behavior in the kernel tree. Operationally, verify whether ESP-in-TCP/IPsec is enabled or required on the host, then test representative VPN/IPsec traffic after patching to ensure no regressions. Review kernel logs before and after remediation for KASAN, slab, page fault, general protection fault, or call traces involving espintcp_sendmsg(), espintcp_push_msgs(), XFRM, or TCP send functions.

Typical attack path

1. Identify a Linux system that uses XFRM/IPsec ESP-in-TCP encapsulation.
2. Obtain a position that can generate or influence ESP-in-TCP traffic, such as a local sender, VPN/IPsec component, or authenticated network peer.
3. Create traffic patterns that cause blocking sends or send-buffer pressure so an ESP-in-TCP transmit remains partially in progress.
4. Trigger a subsequent send before the previous partial-send state is fully completed.
5. Cause the vulnerable kernel path to reuse the live partial state and attach stale offset information to a new sk_msg.
6. Induce the TCP send path to process the malformed state, potentially causing an out-of-bounds read, crash, or memory disclosure condition.

How to detect it

To assess possible prior exploitation or triggering, review kernel ring buffer output, persistent system logs, crash dumps, and monitoring data from systems that use XFRM/IPsec ESP-in-TCP. Focus on kernel warnings, oopses, panics, KASAN reports, slab/page allocation errors, and general protection faults near ESP-in-TCP or TCP send paths. Useful sources include dmesg, journald, /var/log/kern.log, /var/log/messages, crash dump repositories such as kdump/vmcore storage, VPN/IPsec service logs, and network telemetry showing unusual bursts, stalls, retransmissions, or connection resets in IPsec-over-TCP sessions. There are no known public exploit artifacts, named threat actors, or ransomware campaigns associated with this issue, so detection should center on behavioral evidence of the vulnerable code path being triggered rather than fixed malware indicators.

• espintcp_sendmsg
• espintcp_push_msgs
• espintcp
• xfrm
• ESP-in-TCP
• BUG: KASAN
• KASAN: slab-out-of-bounds
• KASAN: global-out-of-bounds
• out-of-bounds read
• general protection fault
• kernel BUG
• Oops:
• Call Trace:
• tcp_sendmsg_locked
• sk_msg
• ctx->partial

What your security team should do

• Inventory Linux systems that use XFRM/IPsec, especially ESP-in-TCP encapsulation, VPN gateways, secure network appliances, and hosts running custom or vendor kernels.
• Prioritize patching systems that actively process IPsec-over-TCP traffic or are exposed to untrusted peers, even though EPSS is low and no known exploitation is reported.
• Apply the vendor-provided kernel update containing the upstream ESP-in-TCP partial-send fix and reboot into the updated kernel where required.
• If patching is delayed, disable unused ESP-in-TCP functionality or restrict which peers and local processes can generate IPsec-over-TCP traffic.
• Enable or review kernel crash, oops, and KASAN-style logging on affected systems to detect possible triggering before remediation.
• Monitor threat intelligence for any change in exploit maturity, because kernel memory-safety bugs can become more important if a reliable trigger or exploit technique is published.