netdev - Re: [PATCH net 1/2] tls: handle data disappearing from under the TLS ULP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250806132034.55292365@kernel.org>
Date: Wed, 6 Aug 2025 13:20:34 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Eric Dumazet <edumazet@...gle.com>
Cc: davem@...emloft.net, netdev@...r.kernel.org, pabeni@...hat.com,
 andrew+netdev@...n.ch, horms@...nel.org, borisp@...dia.com,
 john.fastabend@...il.com, shuah@...nel.org,
 linux-kselftest@...r.kernel.org, sd@...asysnail.net, will@...lsroot.io,
 savy@...t3mfailure.io
Subject: Re: [PATCH net 1/2] tls: handle data disappearing from under the
 TLS ULP

On Wed, 6 Aug 2025 11:35:28 -0700 Eric Dumazet wrote:
> > TLS expects that it owns the receive queue of the TCP socket.
> > This cannot be guaranteed in case the reader of the TCP socket
> > entered before the TLS ULP was installed, or uses some non-standard
> > read API (eg. zerocopy ones). Make sure that the TCP sequence
> > numbers match between ->data_ready and ->recvmsg, otherwise
> > don't trust the work that ->data_ready has done.
> >
> > Signed-off-by: William Liu <will@...lsroot.io>
> > Signed-off-by: Savino Dicanosa <savy@...t3mfailure.io>  
> 
> I presume you meant Reported-by tags ?

Oops..

> > Link: https://lore.kernel.org/tFjq_kf7sWIG3A7CrCg_egb8CVsT_gsmHAK0_wxDPJXfIzxFAMxqmLwp3MlU5EHiet0AwwJldaaFdgyHpeIUCS-3m3llsmRzp9xIOBR4lAI=@syst3mfailure.io
> > Fixes: 84c61fe1a75b ("tls: rx: do not use the standard strparser")
> > Signed-off-by: Jakub Kicinski <kuba@...nel.org>
> > ---
> >  include/net/tls.h  |  1 +
> >  net/tls/tls.h      |  2 +-
> >  net/tls/tls_strp.c | 17 ++++++++++++++---
> >  net/tls/tls_sw.c   |  3 ++-
> >  4 files changed, 18 insertions(+), 5 deletions(-)
> >
> > diff --git a/include/net/tls.h b/include/net/tls.h
> > index 857340338b69..37344a39e4c9 100644
> > --- a/include/net/tls.h
> > +++ b/include/net/tls.h
> > @@ -117,6 +117,7 @@ struct tls_strparser {
> >         bool msg_ready;
> >
> >         struct strp_msg stm;
> > +       u32 copied_seq;  
> 
> Can a 2^32 wrap occur eventually ?

Hm, good point. Is it good enough if we also check it in data_ready?
That way we should notice that someone is eating our data before
the seq had a chance to wrap?