[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <A4CFC6DF-2519-4286-9CF2-6994500EFB86@gmail.com>
Date: Mon, 17 Jun 2019 10:14:12 -0700
From: "Jonathan Lemon" <jonathan.lemon@...il.com>
To: "Eric Dumazet" <edumazet@...gle.com>
Cc: "David S . Miller" <davem@...emloft.net>,
netdev <netdev@...r.kernel.org>,
"Eric Dumazet" <eric.dumazet@...il.com>,
"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
"Jonathan Looney" <jtl@...flix.com>,
"Neal Cardwell" <ncardwell@...gle.com>,
"Tyler Hicks" <tyhicks@...onical.com>,
"Yuchung Cheng" <ycheng@...gle.com>,
"Bruce Curtis" <brucec@...flix.com>
Subject: Re: [PATCH net 1/4] tcp: limit payload size of sacked skbs
On 17 Jun 2019, at 10:03, Eric Dumazet wrote:
> Jonathan Looney reported that TCP can trigger the following crash
> in tcp_shifted_skb() :
>
> BUG_ON(tcp_skb_pcount(skb) < pcount);
>
> This can happen if the remote peer has advertized the smallest
> MSS that linux TCP accepts : 48
>
> An skb can hold 17 fragments, and each fragment can hold 32KB
> on x86, or 64KB on PowerPC.
>
> This means that the 16bit witdh of TCP_SKB_CB(skb)->tcp_gso_segs
> can overflow.
>
> Note that tcp_sendmsg() builds skbs with less than 64KB
> of payload, so this problem needs SACK to be enabled.
> SACK blocks allow TCP to coalesce multiple skbs in the retransmit
> queue, thus filling the 17 fragments to maximal capacity.
>
> CVE-2019-11477 -- u16 overflow of TCP_SKB_CB(skb)->tcp_gso_segs
>
> Fixes: 832d11c5cd07 ("tcp: Try to restore large SKBs while SACK
> processing")
> Signed-off-by: Eric Dumazet <edumazet@...gle.com>
> Reported-by: Jonathan Looney <jtl@...flix.com>
> Acked-by: Neal Cardwell <ncardwell@...gle.com>
> Reviewed-by: Tyler Hicks <tyhicks@...onical.com>
Acked-by: Jonathan Lemon <jonathan.lemon@...il.com>
Powered by blists - more mailing lists