Linux kernel (net/tls): KTLS never supported disconnect, but nothing stopped it. A connect(AF_UNSPEC) on a TLS socket

Impact

KTLS never supported disconnect, but nothing stopped it. A connect(AF_UNSPEC) on a TLS socket leaves the ULP, the strparser anchor and any NIC offload context pointing at torn-down state, and the receive path then walks it - the reported symptom is a warning in tls_strp_msg_load, with the underlying state confusion reachable in several worse shapes.

Who can reach it

Any unprivileged local process on the node can do it against its own socket: enable kTLS with setsockopt, then disconnect and keep reading. No device node, no capability, no cooperating peer. Every tenant container with a normal socket API reaches this.

What to do

Boot a kernel carrying the linked stable commits (which make disconnect on a TLS socket return an error). Interim: none at the tenant boundary - the syscall sequence is ordinary socket usage.

References

Related entries

• Linux kernel (net/tls): A BPF verdict that grows the scatterlist (bpf_msg_push_data) combined with a cork_bytes settingCVE-2025-38166 · Linux kernel (net/tls)High
• Linux kernel (net/tls): KTLS assumes it owns the TCP receive queue. When another reader drains bytes first, the oldCVE-2025-38616 · Linux kernel (net/tls)High
• 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