Re: [PATCH net] net/tls: Consume empty data records in tls_sw_read_sock()

[Sabrina Dubroca <sd@queasysnail.net>]

2026-07-02, 15:52:49 -0400, Chuck Lever wrote:
> 
> 
> On Thu, Jul 2, 2026, at 2:05 PM, Sabrina Dubroca wrote:
> > 2026-06-30, 15:15:51 -0400, Chuck Lever wrote:
> >> A peer may send a zero-length TLS application_data record; TLS 1.3
> >> explicitly permits these as a traffic-analysis countermeasure (RFC
> >> 8446, Section 5.1). After decryption such a record has full_len ==
> >> 0. tls_sw_read_sock() hands it to the read_actor, which has no
> >> payload to consume and returns zero. The loop treats a zero return
> >> as backpressure (used <= 0), requeues the skb at the head of
> >> rx_list, and stops. rx_list is serviced head-first on the next
> >> call, so the empty record is dequeued, fails the same way, and is
> >> requeued again; every later record on the connection is blocked
> >> behind it.
> >> 
> >> tls_sw_recvmsg() does not stall on this: a zero-length data record
> >> copies nothing and falls through to consume_skb(). Mirror that in
> >> the read_sock() path by recognizing an empty data record before
> >> the actor runs, consuming it, and continuing.
> >> 
> >> Fixes: 662fbcec32f4 ("net/tls: implement ->read_sock()")
> >> Signed-off-by: Chuck Lever <cel@kernel.org>
> >> ---
> >>  net/tls/tls_sw.c | 11 +++++++++++
> >>  1 file changed, 11 insertions(+)
> >
> > Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
> >
> > I think tls_sw_splice_read() suffers from a similar issue (returning 0
> > even though more data may be available). Sashiko agrees, and also
> > found a few more pre-existing issues.
> 
> Do you want a v2 series with those issues addressed?

I'd be ok with this patch going in on its own, and the other issues
being addressed separately. If you have time to look into those,
that'd be great.

-- 
Sabrina