Linux kernel (net/tls): A zero-length record already sitting on the rx_list breaks the invariant that zero-copy decrypt

Impact

A zero-length record already sitting on the rx_list breaks the invariant that zero-copy decrypt never has to queue an skb. The receive path then tries to queue a record it decrypted straight into the user buffer and has no skb to work with, corrupting the receive state of a connection a remote peer controls.

Who can reach it

Remote: the peer sends a zero-length TLS record and then a record of a different type, which is entirely within its control on any kTLS connection. Applies to any tenant-facing or fabric-facing kTLS RX socket on the node; no local privilege required.

What to do

Boot a kernel carrying the linked stable commits. Interim: terminate TLS in userspace for connections to untrusted peers.

References

Related entries

• Linux kernel (net/tls): When the socket buffer is too small to hold a whole record, kTLS parses early and re-parses asCVE-2025-39946 · Linux kernel (net/tls)Critical
• Linux kernel (net/tls): If the skb clone that pins the input buffer for an async decrypt cannot be allocated, kTLSCVE-2025-40176 · Linux kernel (net/tls)Critical
• Linux kernel (net/tls): Closing a kTLS socket cancelled the transmit work item, but the write-space callback couldCVE-2026-23240 · Linux kernel (net/tls)Critical
• Linux kernel (net/tls): When the crypto engine backlogs a kTLS encrypt request, both the async completion callback andCVE-2026-31533 · Linux kernel (net/tls)Critical
• Linux kernel (net/tls): A particular kTLS ring state builds a scatterlist whose chain link points directly at anotherCVE-2026-64046 · Linux kernel (net/tls)Critical
• Linux kernel (net/tls): When the kTLS transmit scatterlist ring wraps, the chain link that stitches the tail back toCVE-2026-64047 · Linux kernel (net/tls)Critical