ACK/Cmnt[P/N]: [SRU][N/P/Q][PATCH 0/1] CVE-2025-38616
Tim Whisonant
tim.whisonant at canonical.com
Mon Sep 15 23:53:26 UTC 2025
On Thu, Sep 11, 2025 at 02:46:46PM +0200, Stefan Bader wrote:
> On 25/08/2025 22:54, Tim Whisonant wrote:
> > SRU Justification:
> >
> > [Impact]
> >
> > tls: handle data disappearing from under the TLS ULP
> >
> > 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). Replace the WARN_ON() and a buggy
> > early exit (which leaves anchor pointing to a freed skb) with real
> > error handling. Wipe the parsing state and tell the reader to retry.
> >
> > We already reload the anchor every time we (re)acquire the socket lock,
> > so the only condition we need to avoid is an out of bounds read
> > (not having enough bytes in the socket for previously parsed record len).
> >
> > If some data was read from under TLS but there's enough in the queue
> > we'll reload and decrypt what is most likely not a valid TLS record.
> > Leading to some undefined behavior from TLS perspective (corrupting
> > a stream? missing an alert? missing an attack?) but no kernel crash
> > should take place.
> >
> > [Fix]
> >
> > Questing: applied Noble patch
> > Plucky: applied Noble patch
> > Noble: cherry picked from upstream
> > Jammy: not affected
> > Focal: not affected
> > Bionic: not affected
> > Xenial: not affected
> > Trusty: not affected
> >
> > [Test Plan]
> >
> > Compile and boot tested.
> >
> > [Where problems could occur]
> >
> > The changes appear in the TLS stream parsing logic.
> > Issues might manifest as mal-formatted packets or packet
> > errors.
> >
> > Jakub Kicinski (1):
> > tls: handle data disappearing from under the TLS ULP
> >
> > net/tls/tls.h | 2 +-
> > net/tls/tls_strp.c | 11 ++++++++---
> > net/tls/tls_sw.c | 3 ++-
> > 3 files changed, 11 insertions(+), 5 deletions(-)
> >
> This probably got thrown off by the NACK[Q]. I assume it still is needed for
> P/N...
>
> Acked-by: Stefan Bader <stefan.bader at canonical.com>
It is. Thank you for the ACK.
> --
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team
More information about the kernel-team
mailing list