CVE-2026-74611

A flaw was found in the Linux kernel's Transport Layer Security (TLS) 1.3 implementation. When processing TLS 1.3 records with optimistic zero-copy enabled, the tls_decrypt_sg() function fails to properly restore the message iterator during a retry. A remote attacker, by sending a specially crafted TLS 1.3 control record, can exploit this to cause the kernel to write decrypted data to unintended memory locations. This can lead to data corruption or potentially information disclosure.

A user-buffer overwrite can occur in the Linux kernel TLS 1.3 receive path due to incorrect handling of the message iterator during an optimistic zero-copy retry. tls_decrypt_sg() advances msg->msg_iter while mapping the caller-provided iovecs for the optimistic zero-copy receive path. If the decrypted TLS 1.3 record is subsequently determined not to be unpadded application data, tls_decrypt_sw() falls back to decrypting through a kernel skb. Before the fix, this retry occurred without restoring the iterator to its original position.

As a result, the subsequent copy from the skb starts at the already advanced iterator position and can write decrypted peer-controlled data into later portions of the caller-provided iovecs. recvmsg() nevertheless reports only the length associated with the retried receive operation. The receiving application can therefore observe memory beyond the range implied by the recvmsg() return value being unexpectedly modified.

The vulnerable path is remotely triggerable by a TLS peer when the receiving application uses kernel TLS (kTLS) with TLS 1.3 RX and enables TLS_RX_EXPECT_NO_PAD. A peer can then send a TLS record, such as a control record, that causes the optimistic zero-copy path to fall back to the retry path.

The directly demonstrated impact is corruption of the receiving process's user buffers. This is not an arbitrary kernel-memory write: the erroneous copy remains within user iovec memory previously supplied by the receiving application to recvmsg(). No kernel memory corruption, kernel privilege escalation, or arbitrary code execution has been demonstrated. Depending on how the affected application allocates and subsequently interprets its receive buffers, the unexpected overwrite can corrupt application state or cause application-level denial of service.

Integrity impact is therefore directly supported, while availability impact is application-dependent. Confidentiality impact is less direct because the primitive itself writes peer-controlled decrypted data rather than exposing kernel or process memory to the attacker. A paranoid assessment may retain limited confidentiality and integrity impact.

The practical assessment therefore accounts for the remotely reachable attack surface while recognizing the specific kTLS configuration prerequisite and the fact that the demonstrated overwrite is confined to caller-provided user buffers rather than kernel memory.

The CVSS score(s) listed for this vulnerability do not reflect the associated product's status, and are included for informational purposes to better understand the severity of this vulnerability.

To mitigate this issue, prevent module tls from being loaded. Please see https://access.redhat.com/solutions/41278 for how to blacklist a kernel module to prevent it from loading automatically.