ACK: [SRU][N/P][PATCH 0/1] CVE-2025-39682

[Bethany Jamison]

On 9/8/25 5:52 PM, Tim Whisonant wrote:
> SRU Justification:
>
> [Impact]
>
> tls: fix handling of zero-length records on the rx_list
>
> Each recvmsg() call must process either
>   - only contiguous DATA records (any number of them)
>   - one non-DATA record
>
> If the next record has different type than what has already been
> processed we break out of the main processing loop. If the record
> has already been decrypted (which may be the case for TLS 1.3 where
> we don't know type until decryption) we queue the pending record
> to the rx_list. Next recvmsg() will pick it up from there.
>
> Queuing the skb to rx_list after zero-copy decrypt is not possible,
> since in that case we decrypted directly to the user space buffer,
> and we don't have an skb to queue (darg.skb points to the ciphertext
> skb for access to metadata like length).
>
> Only data records are allowed zero-copy, and we break the processing
> loop after each non-data record. So we should never zero-copy and
> then find out that the record type has changed. The corner case
> we missed is when the initial record comes from rx_list, and it's
> zero length.
>
> [Fix]
>
> 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 change affects the main TLS receive handler for network
> packets. Issues might appear as missed network packets or
> mishandling of inbound packets.
>
> Jakub Kicinski (1):
>    tls: fix handling of zero-length records on the rx_list
>
>   net/tls/tls_sw.c | 7 ++++++-
>   1 file changed, 6 insertions(+), 1 deletion(-)
>
Acked-by: Bethany Jamison <bethany.jamison at canonical.com>