NACK: [SRU][N/P/Q][PATCH 0/1] CVE-2025-38616
Tim Whisonant
tim.whisonant at canonical.com
Sat Sep 27 00:15:18 UTC 2025
Will send a v2.
On Mon, Aug 25, 2025 at 01:54:52PM -0700, 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(-)
>
> --
> 2.43.0
>
More information about the kernel-team
mailing list