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

John Cabaj john.cabaj at canonical.com
Fri Oct 24 02:16:55 UTC 2025


On 10/14/25 6:18 PM, Tim Whisonant wrote:
> SRU Justification:
> 
> [Impact]
> 
> tls: make sure to abort the stream if headers are bogus
> 
> Normally we wait for the socket to buffer up the whole record
> before we service it. If the socket has a tiny buffer, however,
> we read out the data sooner, to prevent connection stalls.
> Make sure that we abort the connection when we find out late
> that the record is actually invalid. Retrying the parsing is
> fine in itself but since we copy some more data each time
> before we parse we can overflow the allocated skb space.
> 
> Constructing a scenario in which we're under pressure without
> enough data in the socket to parse the length upfront is quite
> hard. syzbot figured out a way to do this by serving us the header
> in small OOB sends, and then filling in the recvbuf with a large
> normal send.
> 
> Make sure that tls_rx_msg_size() aborts strp, if we reach
> an invalid record there's really no way to recover.
> 
> [Fix]
> 
> Plucky:   cherry picked from upstream
> 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 affect the net TLS stream parser. Issues might
> arise as failures to decode encrypted streams while in
> the state created by the syzbot check mentioned above.
> 
> [Notes]
> 
> v2 - Review of v1 discovered that the patch no longer applied
> to the Plucky branch. v2 was created by rebasing the branch
> and cherry-picking the fix commit to Plucky.
> 
> Jakub Kicinski (1):
>    tls: make sure to abort the stream if headers are bogus
> 
>   net/tls/tls.h      |  1 +
>   net/tls/tls_strp.c | 14 +++++++++-----
>   net/tls/tls_sw.c   |  3 +--
>   3 files changed, 11 insertions(+), 7 deletions(-)
> 

Acked-by: John Cabaj <john.cabaj at canonical.com>




More information about the kernel-team mailing list