Executive brief
The Linux kernel's TLS (Transport Layer Security) receive path contains a memory corruption bug in the optimized decryption handler for TLS 1.3 connections. When a TLS peer sends certain control records after the receiver enables the TLS_RX_EXPECT_NO_PAD option, decrypted data can be written to the wrong location in memory, potentially overwriting subsequent data in the application's receive buffers and corrupting application data.
Technical details
This is a memory corruption vulnerability in the TLS receive path (net/tls/tls_sw.c). The `tls_decrypt_sg()` function advances the message iterator (`msg->msg_iter`) when attempting an optimistic zero-copy decryption path for TLS 1.3. If the decrypted record is not unpadded application data (e.g., it's a control record), the code falls back to `tls_decrypt_sw()` with a kernel buffer, but fails to revert the previously-advanced iterator. This causes subsequent data copies to write decrypted bytes at an incorrect offset in the caller's iovec buffers, while `recvmsg()` reports only the shorter post-retry length. The vulnerability is triggered when a TLS peer sends a non-application-data record after `TLS_RX_EXPECT_NO_PAD` is enabled. The fix reverts the iterator before retrying the decryption without zero-copy.
Affected products
- Linux Linux kernel Vulnerable versions include kernels with commit ce61327ce989 (TLS 1.3 optimistic zero-copy decryption) through the fix commit 1c8629651cb54f7b51db8fc0b1a9944e4a4b0f5e (2026-08-06)
Timeline
- 2026-08-22: disclosed: Published as CVE-2026-74611
- 2026-08-06: patched: Fix committed upstream: 1c8629651cb54f7b51db8fc0b1a9944e4a4b0f5e
- 2026-08-04: other: Patch authored by Jérémy Jean