Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp3652634pxv; Mon, 26 Jul 2021 08:46:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxFjsBO+Z9njC5jpyu2HkFCBujwTsBXMgX9ZVCw5Bji+yZ7GbscCcygLosH6PR+BgmH9Jld X-Received: by 2002:a6b:b883:: with SMTP id i125mr15626203iof.104.1627314414169; Mon, 26 Jul 2021 08:46:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627314414; cv=none; d=google.com; s=arc-20160816; b=J1y3Fsco7ffhf7RIwdx9lsYm4B5o33w8eO6ne/gq/2x9yxAeiDte16q6PNkLV1EqTD eAct7DRZW693vvmTSNaoevE5QW0NcFVsy34iFKtwBRRyYf2P48Nk6bq61DxG0fG+HfJd +R1TTSN1CiEW2J9dGbZp7aAKZAfUvyeZtTBvoSWk5e3Lo5b/PmETvn2ihXOCwI/qhoQI rMtVzWWjB8AujixnSMwBNqNLjMLsPwhk5vUmXb+mfQNebMJfpgreQIufSZB3XVIb+V4/ tNWePRIw4qzyOhhiwQD8GoXbpWa/FhFoWptIRa2mdaGvumM7AMG9awdEL9sEKv1sGUAP Ak2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=nBeTgHySrIxRUIopohitJNTMBV6b+XMO8iBx/hWdT8I=; b=bD0sb/nzqJ9o2evBNUDkQDLZ9bneX/5p7jrMxOh2liMCVnYQDqIhmLOXzEq0seohtZ WsfoVNXvmcJ1nxKtVwTGXn0ZbGz+83uruybIVp2U0rb8KrTfJxBU84G9acDtGJZZUYwa alKQjgWiQtPt2SplaLGAvl/ElJVW/oU/bJIBQqWccBN420F8bBkE98jKdF0WhwbW5J9Y x9edgOHjbSS7eLDKKfKuQf6237rMjuSXSgr3OABZakUCb7f4PxwlomYmJweUFWkpE+ut rmwQH/p/cGR7rp7zPyYNwiqOvNOdM95qSs2fGcVv8w0SYPK38gGPoZizY/p5HGBy7qhN r8qQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Nbe2FV9g; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g7si351001iov.41.2021.07.26.08.46.42; Mon, 26 Jul 2021 08:46:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Nbe2FV9g; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235888AbhGZPF3 (ORCPT + 99 others); Mon, 26 Jul 2021 11:05:29 -0400 Received: from mail.kernel.org ([198.145.29.99]:44812 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235759AbhGZPEe (ORCPT ); Mon, 26 Jul 2021 11:04:34 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 34A8360F59; Mon, 26 Jul 2021 15:45:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1627314302; bh=pKGsA0o7tsKK9wu1M2C4XO+T9juHoxK8ID3HJqaXoRs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Nbe2FV9gQOtnKteGqoF2SYMAne0xuIw0sVQs32yzJj2WLA4VJkMQicKoZGSzrHOAJ XvEDAmW18ZzQ2p3cM1dbxiwZeu37gNimD1g+PiTd0QdqnnGrRpU3gUbNTMa04xEnM+ IxVAMrZrypPuvtsF8kIwcFcYVNZMy49NbpEjTSBI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Eric Dumazet , =?UTF-8?q?Maciej=20=C5=BBenczykowski?= , Martin KaFai Lau , "David S. Miller" Subject: [PATCH 4.9 23/60] ipv6: tcp: drop silly ICMPv6 packet too big messages Date: Mon, 26 Jul 2021 17:38:37 +0200 Message-Id: <20210726153825.599731675@linuxfoundation.org> X-Mailer: git-send-email 2.32.0 In-Reply-To: <20210726153824.868160836@linuxfoundation.org> References: <20210726153824.868160836@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Eric Dumazet commit c7bb4b89033b764eb07db4e060548a6311d801ee upstream. While TCP stack scales reasonably well, there is still one part that can be used to DDOS it. IPv6 Packet too big messages have to lookup/insert a new route, and if abused by attackers, can easily put hosts under high stress, with many cpus contending on a spinlock while one is stuck in fib6_run_gc() ip6_protocol_deliver_rcu() icmpv6_rcv() icmpv6_notify() tcp_v6_err() tcp_v6_mtu_reduced() inet6_csk_update_pmtu() ip6_rt_update_pmtu() __ip6_rt_update_pmtu() ip6_rt_cache_alloc() ip6_dst_alloc() dst_alloc() ip6_dst_gc() fib6_run_gc() spin_lock_bh() ... Some of our servers have been hit by malicious ICMPv6 packets trying to _increase_ the MTU/MSS of TCP flows. We believe these ICMPv6 packets are a result of a bug in one ISP stack, since they were blindly sent back for _every_ (small) packet sent to them. These packets are for one TCP flow: 09:24:36.266491 IP6 Addr1 > Victim ICMP6, packet too big, mtu 1460, length 1240 09:24:36.266509 IP6 Addr1 > Victim ICMP6, packet too big, mtu 1460, length 1240 09:24:36.316688 IP6 Addr1 > Victim ICMP6, packet too big, mtu 1460, length 1240 09:24:36.316704 IP6 Addr1 > Victim ICMP6, packet too big, mtu 1460, length 1240 09:24:36.608151 IP6 Addr1 > Victim ICMP6, packet too big, mtu 1460, length 1240 TCP stack can filter some silly requests : 1) MTU below IPV6_MIN_MTU can be filtered early in tcp_v6_err() 2) tcp_v6_mtu_reduced() can drop requests trying to increase current MSS. This tests happen before the IPv6 routing stack is entered, thus removing the potential contention and route exhaustion. Note that IPv6 stack was performing these checks, but too late (ie : after the route has been added, and after the potential garbage collect war) v2: fix typo caught by Martin, thanks ! v3: exports tcp_mtu_to_mss(), caught by David, thanks ! Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Reviewed-by: Maciej Żenczykowski Cc: Martin KaFai Lau Acked-by: Martin KaFai Lau Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- net/ipv4/tcp_output.c | 1 + net/ipv6/tcp_ipv6.c | 19 +++++++++++++++++-- 2 files changed, 18 insertions(+), 2 deletions(-) --- a/net/ipv4/tcp_output.c +++ b/net/ipv4/tcp_output.c @@ -1383,6 +1383,7 @@ int tcp_mtu_to_mss(struct sock *sk, int return __tcp_mtu_to_mss(sk, pmtu) - (tcp_sk(sk)->tcp_header_len - sizeof(struct tcphdr)); } +EXPORT_SYMBOL(tcp_mtu_to_mss); /* Inverse of above */ int tcp_mss_to_mtu(struct sock *sk, int mss) --- a/net/ipv6/tcp_ipv6.c +++ b/net/ipv6/tcp_ipv6.c @@ -307,11 +307,20 @@ failure: static void tcp_v6_mtu_reduced(struct sock *sk) { struct dst_entry *dst; + u32 mtu; if ((1 << sk->sk_state) & (TCPF_LISTEN | TCPF_CLOSE)) return; - dst = inet6_csk_update_pmtu(sk, READ_ONCE(tcp_sk(sk)->mtu_info)); + mtu = READ_ONCE(tcp_sk(sk)->mtu_info); + + /* Drop requests trying to increase our current mss. + * Check done in __ip6_rt_update_pmtu() is too late. + */ + if (tcp_mtu_to_mss(sk, mtu) >= tcp_sk(sk)->mss_cache) + return; + + dst = inet6_csk_update_pmtu(sk, mtu); if (!dst) return; @@ -390,6 +399,8 @@ static void tcp_v6_err(struct sk_buff *s } if (type == ICMPV6_PKT_TOOBIG) { + u32 mtu = ntohl(info); + /* We are not interested in TCP_LISTEN and open_requests * (SYN-ACKs send out by Linux are always <576bytes so * they should go through unfragmented). @@ -400,7 +411,11 @@ static void tcp_v6_err(struct sk_buff *s if (!ip6_sk_accept_pmtu(sk)) goto out; - WRITE_ONCE(tp->mtu_info, ntohl(info)); + if (mtu < IPV6_MIN_MTU) + goto out; + + WRITE_ONCE(tp->mtu_info, mtu); + if (!sock_owned_by_user(sk)) tcp_v6_mtu_reduced(sk); else if (!test_and_set_bit(TCP_MTU_REDUCED_DEFERRED,