Linux kernel (net/tls): KTLS assumes it owns the TCP receive queue. When another reader drains bytes first, the old

Impact

KTLS assumes it owns the TCP receive queue. When another reader drains bytes first, the old code hit a WARN and returned early leaving the strparser anchor pointing at a freed skb, and could read past the end of what is actually queued. Beyond the memory-safety hit, the parser can then decrypt something that is not a valid record - a missed alert or a missed attack on that stream.

Who can reach it

Local: a process that read from the TCP socket before the TLS ULP was installed, or that uses a non-standard/zerocopy read API on the same socket. That is a same-container or same-process condition rather than a cross-tenant one, but it is unprivileged and needs no device node; the peer supplies the record data that gets misparsed.

What to do

Boot a kernel carrying the linked stable commits. Interim: install the TLS ULP before any read on the socket and do not mix zerocopy receive with kTLS.

References

Related entries

• Linux kernel (net/tls): The kTLS device-offload setup resolved the socket's netdevice outside RCU, so the net_device itCVE-2025-40149 · Linux kernel (net/tls)High
• Linux kernel (net/tls): A receiver that holds its TCP window at zero keeps the kTLS sender blocked inside tx_lockCVE-2023-54306 · Linux kernel (net/tls)High
• Linux kernel (net/tls): If a page allocation fails while the TLS strparser is copying a partial record, the receiveCVE-2025-38018 · Linux kernel (net/tls)High
• Linux kernel (net/tls): The queue that pins encrypted input buffers while the AEAD engine still references them wasCVE-2026-23414 · Linux kernel (net/tls)High
• Linux kernel (net/tls): When kTLS RX offload fails at tls_dev_add, the rollback frees the software context but neverCVE-2026-52974 · Linux kernel (net/tls)High
• Linux kernel (net/tls): A remote peer sends a zero-length TLS 1.3 application_data record - which the RFC explicitlyCVE-2026-72330 · Linux kernel (net/tls)High