Hi, On 10/2/2026 6:41 AM, Chuck Lever wrote:
tls_sw_splice_read() currently returns at most 16KiB (one record) per call. You may add a loop like the one in tls_sw_recvmsg().Commit 3be28e2c9cd0 ("net/tls: Consume empty data records in tls_sw_read_sock()") fixed one reader. TLS 1.2 and TLS 1.3 both permit a zero-length application_data record as a traffic-analysis countermeasure (RFC 5246, Section 6.2.1; RFC 8446, Section 5.1), so a peer that pads its stream emits them by design. The other two software readers still mishandle them. splice(2) reports an empty record as EOF, and the caller tears down a connection that is still live. recvmsg(2) makes no progress on one, so a peer that streams them holds the caller in the kernel past SIGKILL. With MSG_PEEK or async decryption, each record is also queued on rx_list, which grows without bound.This series supersedes "[PATCH net] tls: skip empty data records in tls_sw_splice_read()", which fixes the splice case alone: https://lore.kernel.org/netdev/[email protected]/
Best regards, Qingfang
