Linux kernel (net/tls): A remote peer sends a zero-length TLS 1.3 application_data record - which the RFC explicitly

Impact

A remote peer sends a zero-length TLS 1.3 application_data record - which the RFC explicitly permits as a traffic-analysis countermeasure, so this is legal traffic, not an attack payload - and the kTLS read_sock consumer treats the zero bytes consumed as backpressure. The empty record is requeued at the head of the receive list and retried forever, so every subsequent record on that connection is blocked behind it. One legal record from the far end permanently wedges a kTLS connection carrying storage or control traffic, with no way to recover short of tearing the connection down.

Who can reach it

Any remote TLS peer, with no credentials and no local access - it only has to be the other end of an established kTLS session. Conditional on the consumer using the read_sock path rather than recvmsg: that means sockmap/BPF splicing datapaths and in-kernel consumers, which is exactly how a service mesh or storage proxy terminates kTLS. Plain recvmsg users are unaffected because that path already consumes empty records correctly.

What to do

Boot a kernel carrying the fix commits below (no fixed stable version published). Interim control: route kTLS traffic through recvmsg-based consumers rather than sockmap/read_sock splicing until patched, and add connection-level liveness timeouts so a wedged connection is torn down instead of stalling a storage path indefinitely.

References