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

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

[Chuck Lever]

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(+)

diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index 9324e4ed20a3..d4afc90fd796 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -2115,6 +2115,17 @@ int tls_sw_read_sock(struct sock *sk, read_descriptor_t *desc,
 			goto read_sock_requeue;
 		}
 
+		/* An empty data record (legal in TLS 1.3) gives a zero
+		 * read_actor return, indistinguishable from the consumer
+		 * stalling; the used <= 0 path would requeue it at the
+		 * head of rx_list and block all later records. Consume it
+		 * here instead.
+		 */
+		if (rxm->full_len == 0) {
+			consume_skb(skb);
+			continue;
+		}
+
 		used = read_actor(desc, skb, rxm->offset, rxm->full_len);
 		if (used <= 0) {
 			if (!copied)
-- 
2.54.0

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

[Sabrina Dubroca]

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.

-- 
Sabrina

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

[Chuck Lever]

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?


-- 
Chuck Lever

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

[Sabrina Dubroca]

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