CVE-2026-74611: Linux Kernel TLS Use-After-Free Vulnerability

CVE-2026-74611 Overview

CVE-2026-74611 is a Linux kernel vulnerability in the Transport Layer Security (TLS) receive path. The flaw resides in tls_decrypt_sg() and tls_decrypt_sw(), which handle the optimistic TLS 1.3 zero-copy decryption path. When a decrypted record turns out not to be unpadded application data, the code retries decryption into a kernel skb but fails to rewind msg->msg_iter after it was advanced during user page mapping. A remote TLS peer can trigger this condition once the receiver enables TLS_RX_EXPECT_NO_PAD, causing decrypted bytes to be written past the length reported by recvmsg().

Critical Impact
A remote TLS peer can corrupt user-space memory in iovecs beyond the length returned by recvmsg(), leading to data integrity loss and potential memory disclosure or corruption in TLS 1.3 clients.

Affected Products

Linux kernel builds enabling kernel TLS (kTLS) receive-path offload
Linux kernel TLS 1.3 receivers using TLS_RX_EXPECT_NO_PAD
Distributions shipping the affected net/tls subsystem prior to the fix commits

Discovery Timeline

2026-08-22 - CVE-2026-74611 published to the National Vulnerability Database
2026-08-25 - Last updated in NVD database

Technical Details for CVE-2026-74611

Vulnerability Analysis

The Linux kernel TLS receive code implements an optimistic zero-copy path for TLS 1.3. In tls_decrypt_sg(), the kernel maps user pages directly and advances msg->msg_iter to reflect the mapped range. This design avoids an extra copy when the record decrypts cleanly into unpadded application data.

The defect appears in the fallback path. If the decrypted record is not unpadded application data (for example, a TLS 1.3 control record), tls_decrypt_sw() retries decryption into a kernel-owned socket buffer. The retry logic does not revert msg_iter to its pre-mapping position. The subsequent copy from the kernel skb writes plaintext bytes into user memory at an offset past the intended region, while recvmsg() reports only the post-retry byte count to the caller.

The result is silent memory corruption of iovec buffers positioned after the returned data window. A malicious peer can influence which record types trigger the retry path, giving remote control over when the out-of-bounds write occurs.

Root Cause

The root cause is missing state restoration on an error/retry path — an iterator invariant violation. tls_decrypt_sg() mutates msg->msg_iter as a side effect of user page mapping but does not roll it back when tls_decrypt_sw() falls back to a non-zero-copy retry. This is an out-of-bounds write triggered by improper handling of a control-flow transition.

Attack Vector

Exploitation requires a TLS 1.3 session where the receiver has enabled TLS_RX_EXPECT_NO_PAD on a kTLS socket. A remote TLS peer sends a record that fails the unpadded application-data check after the optimistic mapping has already advanced the iterator. The kernel then writes decrypted bytes into caller iovecs beyond the length that recvmsg() reports. No local access or authentication to the target host is required beyond an established TLS session.

No public exploit or proof-of-concept is currently available. A kernel selftest sending a TLS 1.3 control record with TLS_RX_EXPECT_NO_PAD enabled reproduces the condition and verifies that recvmsg() no longer overwrites later iovecs. See the Linux kernel fix commit 1c862965 for technical details.

Detection Methods for CVE-2026-74611

Indicators of Compromise

Unexpected corruption or overwritten data in application receive buffers immediately following a recvmsg() call on a kTLS 1.3 socket
Application-layer protocol parsing errors on connections that enable TLS_RX_EXPECT_NO_PAD
Crashes or assertion failures in user-space daemons using kernel TLS offload after receiving TLS 1.3 control records

Detection Strategies

Inventory hosts running kernel versions that include net/tls receive-side changes but predate commits 1c862965, 3c837266, and 68787940
Audit user-space applications that set the TLS_RX_EXPECT_NO_PAD socket option on TLS 1.3 sockets
Use kernel tracing (ftrace, bpftrace) on tls_decrypt_sg and tls_decrypt_sw to observe retry paths in production

Monitoring Recommendations

Monitor TLS termination services and load balancers for anomalous recvmsg() return values relative to observed on-wire record sizes
Alert on kernel warnings, oopses, or memory corruption reports (KASAN, slab-out-of-bounds) in the net/tls code path
Track TLS 1.3 sessions terminating with unusual control record patterns immediately before application errors

How to Mitigate CVE-2026-74611

Immediate Actions Required

Apply the upstream Linux kernel patches referenced in commits 1c8629651cb5, 3c837266a734, and 68787940274e or update to a distribution kernel that includes the backport
Identify all workloads using kernel TLS receive offload with TLS 1.3 and prioritize them for patching
Restart services that hold long-lived kTLS sockets after the kernel update to ensure the fixed code path is active

Patch Information

The fix reverts msg->msg_iter by the number of bytes consumed by the optimistic mapping before retrying without zero-copy. Merged patches are available at kernel.org commit 1c862965, commit 3c837266, and commit 68787940. A selftest accompanies the fix to prevent regression.

Workarounds

Disable the TLS_RX_EXPECT_NO_PAD socket option in applications where it is not strictly required, which removes the trigger condition
Disable kernel TLS receive offload (kTLS RX) and terminate TLS in user space until patched kernels are deployed
Restrict inbound TLS connections to trusted peers where feasible until the kernel patch is applied

bash

# Verify running kernel version and check for the fix
uname -r

# List loaded TLS kernel module and confirm patch status via distro tooling
modinfo tls | grep -E 'version|filename'

# Identify processes using kernel TLS sockets
ss -tie | grep -i tls