[PATCH net] tls: skip empty data records in tls_sw_splice_read()

[PATCH net] tls: skip empty data records in tls_sw_splice_read()

[Qingfang Deng]

tls_sw_splice_read() returns 0 after receiving an empty application
record. This looks like EOF for splice(), even though the connection
remains open and more data may be available.

Consume empty application records and retry the receive path instead,
following the approach used in tls_sw_read_sock() since commit
3be28e2c9cd0 ("net/tls: Consume empty data records in tls_sw_read_sock()").

Fixes: c46234ebb4d1 ("tls: RX path for ktls")
Reported-by: Sabrina Dubroca <sd@queasysnail.net>
Closes: https://lore.kernel.org/netdev/akaoXcfamBp8_mYe@krikkit/
Signed-off-by: Qingfang Deng <qingfang.deng@linux.dev>
---
 net/tls/tls_sw.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index d1ad31986cf2..e23bb8a9dedd 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -2019,6 +2019,7 @@ ssize_t tls_sw_splice_read(struct socket *sock,  loff_t *ppos,
 	if (err)
 		goto splice_read_end;
 
+retry:
 	if (!skb_queue_empty(&ctx->rx_list)) {
 		skb = __skb_dequeue(&ctx->rx_list);
 	} else {
@@ -2048,6 +2049,12 @@ ssize_t tls_sw_splice_read(struct socket *sock,  loff_t *ppos,
 		goto splice_requeue;
 	}
 
+	/* Empty application records must not be reported as EOF. */
+	if (!rxm->full_len) {
+		consume_skb(skb);
+		goto retry;
+	}
+
 	chunk = min_t(unsigned int, rxm->full_len, len);
 	copied = skb_splice_bits(skb, sk, rxm->offset, pipe, chunk, flags);
 	if (copied < 0)
-- 
2.43.0

Re: [PATCH net] tls: skip empty data records in tls_sw_splice_read()

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - Whether the issue was actually triggered, or is only theoretical
   (e.g. found by code inspection). If it was triggered please include
   the symptoms, like the stack trace or error messages.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH net] tls: skip empty data records in tls_sw_splice_read()

[Qingfang Deng]

On 2026/9/30 13:29, netdev-bot+sinfo@kernel.org wrote:
> Hi!
>
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
>
>   - Whether the issue was actually triggered, or is only theoretical
>     (e.g. found by code inspection). If it was triggered please include
>     the symptoms, like the stack trace or error messages.
>
> Please do not repost the series just to address the above. Instead,
> reply to this email with the missing information, so that reviewers
> can take it into account. If the series needs another revision for
> other reasons, please include the information in the commit messages
> then.
>
> The evaluation is done by an LLM so it may be wrong, if you think
> that is the case please reply and explain.

Quoting Sashiko's reply:

> When an application invokes splice() on a TLS 1.3 socket and a 
> 0-length record arrives, rxm->full_len is 0, making chunk 0. 
> net/tls/tls_sw.c:tls_sw_splice_read() { ... chunk = min_t(unsigned 
> int, rxm->full_len, len); copied = skb_splice_bits(skb, sk, 
> rxm->offset, pipe, chunk, flags); if (copied < 0) goto splice_requeue; 
> if (copied < rxm->full_len) { rxm->offset += copied; rxm->full_len -= 
> copied; goto splice_requeue; } consume_skb(skb); splice_read_end: 
> tls_rx_reader_unlock(sk, ctx); return copied ? : err; } Because copied 
> is 0, the copied < rxm->full_len check fails, the SKB is consumed, and 
> the function returns 0. Returning 0 from a splice operation signals 
> End-of-File to userspace, which would erroneously drop the live 
> connection.

Best regards,

Re: [PATCH net] tls: skip empty data records in tls_sw_splice_read()

[Sabrina Dubroca]

2026-09-30, 13:26:36 +0800, Qingfang Deng wrote:
> tls_sw_splice_read() returns 0 after receiving an empty application
> record. This looks like EOF for splice(), even though the connection
> remains open and more data may be available.
> 
> Consume empty application records and retry the receive path instead,
> following the approach used in tls_sw_read_sock() since commit
> 3be28e2c9cd0 ("net/tls: Consume empty data records in tls_sw_read_sock()").

This is similar to what Chuck proposed in July:
https://lore.kernel.org/all/20260726-tls-follow-on-v1-2-99bf4cc1c729@kernel.org

but Chuck's patch had some extra bits (handling of the "released" flag
and of signal_pending).

His series also had a selftest which should be included too
https://lore.kernel.org/all/20260726-tls-follow-on-v1-6-99bf4cc1c729@kernel.org/

-- 
Sabrina

Re: [PATCH net] tls: skip empty data records in tls_sw_splice_read()

[Qingfang Deng]

On 2026/9/30 17:13, Sabrina Dubroca wrote:
> 2026-09-30, 13:26:36 +0800, Qingfang Deng wrote:
>> tls_sw_splice_read() returns 0 after receiving an empty application
>> record. This looks like EOF for splice(), even though the connection
>> remains open and more data may be available.
>>
>> Consume empty application records and retry the receive path instead,
>> following the approach used in tls_sw_read_sock() since commit
>> 3be28e2c9cd0 ("net/tls: Consume empty data records in tls_sw_read_sock()").
> This is similar to what Chuck proposed in July:
> https://lore.kernel.org/all/20260726-tls-follow-on-v1-2-99bf4cc1c729@kernel.org
>
> but Chuck's patch had some extra bits (handling of the "released" flag
> and of signal_pending).
>
> His series also had a selftest which should be included too
> https://lore.kernel.org/all/20260726-tls-follow-on-v1-6-99bf4cc1c729@kernel.org/

Thanks for the information. I prefer his series.


--
pw-bot: cr

Re: [PATCH net] tls: skip empty data records in tls_sw_splice_read()

[Sabrina Dubroca]

2026-09-30, 17:24:18 +0800, Qingfang Deng wrote:
> On 2026/9/30 17:13, Sabrina Dubroca wrote:
> > 2026-09-30, 13:26:36 +0800, Qingfang Deng wrote:
> > > tls_sw_splice_read() returns 0 after receiving an empty application
> > > record. This looks like EOF for splice(), even though the connection
> > > remains open and more data may be available.
> > > 
> > > Consume empty application records and retry the receive path instead,
> > > following the approach used in tls_sw_read_sock() since commit
> > > 3be28e2c9cd0 ("net/tls: Consume empty data records in tls_sw_read_sock()").
> > This is similar to what Chuck proposed in July:
> > https://lore.kernel.org/all/20260726-tls-follow-on-v1-2-99bf4cc1c729@kernel.org
> > 
> > but Chuck's patch had some extra bits (handling of the "released" flag
> > and of signal_pending).
> > 
> > His series also had a selftest which should be included too
> > https://lore.kernel.org/all/20260726-tls-follow-on-v1-6-99bf4cc1c729@kernel.org/
> 
> Thanks for the information. I prefer his series.

Let's see if he has the time/interest to continue work on this (since
he didn't send a v2, I'm guessing not).

Chuck, do you want to pick up that TLS fixes series again, or would
you rather let Qingfang finish off the "splice vs empty record"
patch+selftest based on what you had sent?

-- 
Sabrina

Re: [PATCH net] tls: skip empty data records in tls_sw_splice_read()

[Chuck Lever]

On Wed, Sep 30, 2026, at 2:47 AM, Sabrina Dubroca wrote:
> 2026-09-30, 17:24:18 +0800, Qingfang Deng wrote:
>> On 2026/9/30 17:13, Sabrina Dubroca wrote:
>> > 2026-09-30, 13:26:36 +0800, Qingfang Deng wrote:
>> > > tls_sw_splice_read() returns 0 after receiving an empty application
>> > > record. This looks like EOF for splice(), even though the connection
>> > > remains open and more data may be available.
>> > > 
>> > > Consume empty application records and retry the receive path instead,
>> > > following the approach used in tls_sw_read_sock() since commit
>> > > 3be28e2c9cd0 ("net/tls: Consume empty data records in tls_sw_read_sock()").
>> > This is similar to what Chuck proposed in July:
>> > https://lore.kernel.org/all/20260726-tls-follow-on-v1-2-99bf4cc1c729@kernel.org
>> > 
>> > but Chuck's patch had some extra bits (handling of the "released" flag
>> > and of signal_pending).
>> > 
>> > His series also had a selftest which should be included too
>> > https://lore.kernel.org/all/20260726-tls-follow-on-v1-6-99bf4cc1c729@kernel.org/
>> 
>> Thanks for the information. I prefer his series.
>
> Let's see if he has the time/interest to continue work on this (since
> he didn't send a v2, I'm guessing not).
>
> Chuck, do you want to pick up that TLS fixes series again, or would
> you rather let Qingfang finish off the "splice vs empty record"
> patch+selftest based on what you had sent?

History: I stopped working on that since Jakub seemed to think the
fixes were not worth the trouble, and my objective is to get kTLS
and its kernel consumers in shape to support KeyUpdate.

If you think cleaning up and reposting an old series would be
received well, I can take it up again. (And forgive me, but can
you send along a lore URL so I'm sure I'm working on the correct
one?)


-- 
Chuck Lever (Come to NFS bake-a-thon! https://nfsv4bat.org)

Re: [PATCH net] tls: skip empty data records in tls_sw_splice_read()

[Sabrina Dubroca]

2026-09-30, 06:45:23 -0700, Chuck Lever wrote:
> 
> 
> On Wed, Sep 30, 2026, at 2:47 AM, Sabrina Dubroca wrote:
> > 2026-09-30, 17:24:18 +0800, Qingfang Deng wrote:
> >> On 2026/9/30 17:13, Sabrina Dubroca wrote:
> >> > 2026-09-30, 13:26:36 +0800, Qingfang Deng wrote:
> >> > > tls_sw_splice_read() returns 0 after receiving an empty application
> >> > > record. This looks like EOF for splice(), even though the connection
> >> > > remains open and more data may be available.
> >> > > 
> >> > > Consume empty application records and retry the receive path instead,
> >> > > following the approach used in tls_sw_read_sock() since commit
> >> > > 3be28e2c9cd0 ("net/tls: Consume empty data records in tls_sw_read_sock()").
> >> > This is similar to what Chuck proposed in July:
> >> > https://lore.kernel.org/all/20260726-tls-follow-on-v1-2-99bf4cc1c729@kernel.org
> >> > 
> >> > but Chuck's patch had some extra bits (handling of the "released" flag
> >> > and of signal_pending).
> >> > 
> >> > His series also had a selftest which should be included too
> >> > https://lore.kernel.org/all/20260726-tls-follow-on-v1-6-99bf4cc1c729@kernel.org/
> >> 
> >> Thanks for the information. I prefer his series.
> >
> > Let's see if he has the time/interest to continue work on this (since
> > he didn't send a v2, I'm guessing not).
> >
> > Chuck, do you want to pick up that TLS fixes series again, or would
> > you rather let Qingfang finish off the "splice vs empty record"
> > patch+selftest based on what you had sent?
> 
> History: I stopped working on that since Jakub seemed to think the
> fixes were not worth the trouble, and my objective is to get kTLS
> and its kernel consumers in shape to support KeyUpdate.

I /think/ he meant that some patches in that series were ready to go
in and worthy of being merged quickly, while others were less urgent
and less ready, and could be finished later on (but not necessarily
that the issues shouldn't be fixed at all).

But I guess we could just ask him.

> If you think cleaning up and reposting an old series would be
> received well, I can take it up again. (And forgive me, but can
> you send along a lore URL so I'm sure I'm working on the correct
> one?)

The link was in my previous email:
https://lore.kernel.org/all/20260726-tls-follow-on-v1-2-99bf4cc1c729@kernel.org

-- 
Sabrina

Re: [PATCH net] tls: skip empty data records in tls_sw_splice_read()

[Chuck Lever]

On Wed, Sep 30, 2026, at 7:51 AM, Sabrina Dubroca wrote:
> 2026-09-30, 06:45:23 -0700, Chuck Lever wrote:
>> 
>> 
>> On Wed, Sep 30, 2026, at 2:47 AM, Sabrina Dubroca wrote:

>> > Let's see if he has the time/interest to continue work on this (since
>> > he didn't send a v2, I'm guessing not).
>> >
>> > Chuck, do you want to pick up that TLS fixes series again, or would
>> > you rather let Qingfang finish off the "splice vs empty record"
>> > patch+selftest based on what you had sent?
>> 
>> History: I stopped working on that since Jakub seemed to think the
>> fixes were not worth the trouble, and my objective is to get kTLS
>> and its kernel consumers in shape to support KeyUpdate.
>
> I /think/ he meant that some patches in that series were ready to go
> in and worthy of being merged quickly, while others were less urgent
> and less ready, and could be finished later on (but not necessarily
> that the issues shouldn't be fixed at all).

I recall the use of the word "doubtful". I'm happy to continue to
pursue them, but I don't want to waste reviewer/maintainer time.


> But I guess we could just ask him.

Agreed, I probably misread his comment.


-- 
Chuck Lever (Come to NFS bake-a-thon! https://nfsv4bat.org)