commit e861d0673eb8dc9b616269f70bf8a07d7524877e
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Jun 17 19:52:45 2019 +0200

    Linux 4.14.127

commit f2aa4f1a05e0987e812809dbc489bd294fdae5ae
Author: Eric Dumazet <edumazet@google.com>
Date:   Sat Jun 15 17:47:27 2019 -0700

    tcp: enforce tcp_min_snd_mss in tcp_mtu_probing()
    
    commit 967c05aee439e6e5d7d805e195b3a20ef5c433d6 upstream.
    
    If mtu probing is enabled tcp_mtu_probing() could very well end up
    with a too small MSS.
    
    Use the new sysctl tcp_min_snd_mss to make sure MSS search
    is performed in an acceptable range.
    
    CVE-2019-11479 -- tcp mss hardcoded to 48
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Jonathan Lemon <jonathan.lemon@gmail.com>
    Cc: Jonathan Looney <jtl@netflix.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Cc: Yuchung Cheng <ycheng@google.com>
    Cc: Tyler Hicks <tyhicks@canonical.com>
    Cc: Bruce Curtis <brucec@netflix.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd6f35b8421ff20365ff711c0ac7647fd70e9af7
Author: Eric Dumazet <edumazet@google.com>
Date:   Sat Jun 15 17:44:24 2019 -0700

    tcp: add tcp_min_snd_mss sysctl
    
    commit 5f3e2bf008c2221478101ee72f5cb4654b9fc363 upstream.
    
    Some TCP peers announce a very small MSS option in their SYN and/or
    SYN/ACK messages.
    
    This forces the stack to send packets with a very high network/cpu
    overhead.
    
    Linux has enforced a minimal value of 48. Since this value includes
    the size of TCP options, and that the options can consume up to 40
    bytes, this means that each segment can include only 8 bytes of payload.
    
    In some cases, it can be useful to increase the minimal value
    to a saner value.
    
    We still let the default to 48 (TCP_MIN_SND_MSS), for compatibility
    reasons.
    
    Note that TCP_MAXSEG socket option enforces a minimal value
    of (TCP_MIN_MSS). David Miller increased this minimal value
    in commit c39508d6f118 ("tcp: Make TCP_MAXSEG minimum more correct.")
    from 64 to 88.
    
    We might in the future merge TCP_MIN_SND_MSS and TCP_MIN_MSS.
    
    CVE-2019-11479 -- tcp mss hardcoded to 48
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Suggested-by: Jonathan Looney <jtl@netflix.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Cc: Yuchung Cheng <ycheng@google.com>
    Cc: Tyler Hicks <tyhicks@canonical.com>
    Cc: Bruce Curtis <brucec@netflix.com>
    Cc: Jonathan Lemon <jonathan.lemon@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9daf226ff92679d09aeca1b5c1240e3607153336
Author: Eric Dumazet <edumazet@google.com>
Date:   Sat Jun 15 17:40:56 2019 -0700

    tcp: tcp_fragment() should apply sane memory limits
    
    commit f070ef2ac66716357066b683fb0baf55f8191a2e upstream.
    
    Jonathan Looney reported that a malicious peer can force a sender
    to fragment its retransmit queue into tiny skbs, inflating memory
    usage and/or overflow 32bit counters.
    
    TCP allows an application to queue up to sk_sndbuf bytes,
    so we need to give some allowance for non malicious splitting
    of retransmit queue.
    
    A new SNMP counter is added to monitor how many times TCP
    did not allow to split an skb if the allowance was exceeded.
    
    Note that this counter might increase in the case applications
    use SO_SNDBUF socket option to lower sk_sndbuf.
    
    CVE-2019-11478 : tcp_fragment, prevent fragmenting a packet when the
            socket is already using more than half the allowed space
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Jonathan Looney <jtl@netflix.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Acked-by: Yuchung Cheng <ycheng@google.com>
    Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
    Cc: Bruce Curtis <brucec@netflix.com>
    Cc: Jonathan Lemon <jonathan.lemon@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d632920554c5aec81d8a79c23dac07efcbabbd54
Author: Eric Dumazet <edumazet@google.com>
Date:   Sat Jun 15 17:31:03 2019 -0700

    tcp: limit payload size of sacked skbs
    
    commit 3b4929f65b0d8249f19a50245cd88ed1a2f78cff upstream.
    
    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
    
    Backport notes, provided by Joao Martins <joao.m.martins@oracle.com>
    
    v4.15 or since commit 737ff314563 ("tcp: use sequence distance to
    detect reordering") had switched from the packet-based FACK tracking and
    switched to sequence-based.
    
    v4.14 and older still have the old logic and hence on
    tcp_skb_shift_data() needs to retain its original logic and have
    @fack_count in sync. In other words, we keep the increment of pcount with
    tcp_skb_pcount(skb) to later used that to update fack_count. To make it
    more explicit we track the new skb that gets incremented to pcount in
    @next_pcount, and we get to avoid the constant invocation of
    tcp_skb_pcount(skb) all together.
    
    Fixes: 832d11c5cd07 ("tcp: Try to restore large SKBs while SACK processing")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Jonathan Looney <jtl@netflix.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
    Cc: Yuchung Cheng <ycheng@google.com>
    Cc: Bruce Curtis <brucec@netflix.com>
    Cc: Jonathan Lemon <jonathan.lemon@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b2ea53195d020f0ddd712c176eb2efcf8981a0bf
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Oct 5 22:21:25 2017 -0700

    tcp: reduce tcp_fastretrans_alert() verbosity
    
    commit 8ba6ddaaf86c4c6814774e4e4ef158b732bd9f9f upstream.
    
    With upcoming rb-tree implementation, the checks will trigger
    more often, and this is expected.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Amit Shah <amit@infradead.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>