CVE-2026-74611: tls: rx: restore msg_iter before TLS 1.3 optimistic retry
In the Linux kernel, the following vulnerability has been resolved:
tls: rx: restore msgiter before TLS 1.3 optimistic retry
tlsdecryptsg() advances msg->msgiter when it maps user pages for the optimistic TLS 1.3 zero-copy path. If the decrypted record turns out not to be unpadded application data, tlsdecryptsw() retries into a kernel skb, but leaves the iterator advanced.
The subsequent copy from the skb then writes decrypted bytes again at a later point in the caller iovecs while recvmsg() reports only the post-retry length. A TLS peer can trigger this after the receiver enables TLSRXEXPECTNOPAD.
Revert the iterator by the number of bytes consumed by the optimistic mapping before retrying without zero-copy.
Add a selftest which sends a TLS 1.3 control record with TLSRXEXPECTNOPAD enabled and verifies that recvmsg() does not overwrite later iovecs beyond the returned length.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Linux kernel TLS receive paths are exposed when TLS 1.3 is in use and the receiver has enabled TLS_RX_EXPECT_NO_PAD. The issue is reached through the optimistic zero-copy receive path.
What does an attacker need to do to trigger it?
A TLS peer can trigger the condition by causing a decrypted record to be something other than unpadded application data, such as a TLS 1.3 control record, after TLS_RX_EXPECT_NO_PAD has been enabled by the receiver.
How can I determine whether my application may be affected?
Check whether it uses the Linux kernel TLS receive path with TLS 1.3 and enables TLS_RX_EXPECT_NO_PAD. Affected behavior can overwrite later caller iovecs beyond the length reported by recvmsg() when the optimistic receive attempt retries through a kernel skb.