Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp909511pxb; Wed, 6 Apr 2022 04:01:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwWoD3AtuB5GYS2sVm9KW9I5GBVvxzkOD8EhpZtxkZPyuC6J8DiUurWBZy5H5HaUjJxxDcR X-Received: by 2002:a05:6a00:1745:b0:4fd:a924:fef6 with SMTP id j5-20020a056a00174500b004fda924fef6mr8454043pfc.50.1649242885967; Wed, 06 Apr 2022 04:01:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649242885; cv=none; d=google.com; s=arc-20160816; b=rWbt+SIOZ6WvhRTn2Sd4CONdUdVdNoKi2Zkj1lQiS0VjjJO5v8M9psN9YAioNd9Pbs GyRNuoKJfNgRS0ZMmAhokEOOvVFEzGJK8pK5rBUBFNRae+pIzGqq9BgIbtcICy+OwiKP MNXQbJoelkGf2cWnyDvi7u+Rl/r1BVEQlbDAtVH0kStKibM67hcnJOI69EiabMmeIkB2 KnGAkoR9wdflQtsOK0v7BG25b/RFxfCCgpKzaEW4pdDyPfMNEkS4iT3E0S/KgmD3mhVA 6UjXHBonK2u8mXg0vbatnd+WbxuiU9+17rF6tTE6Cu2/nnGiRGkYm2jRPo+qQ2hZYNhS xRWA== 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=H7gvtXBca7S2I3e7RflftAGwospQ8a3U/Pb9Mzn84bY=; b=n5Fo0hE/Kf1snowc8qlQbVA7w6ZOQCE7XmZTQG2NJL1d7uP60SjcxCEjdvNkSscb1f 4w11HVkTwg7I7h72yQJ1suhg2u1yxs7wOdVDpKXL6jQpPSYn9IBKHSXF73souZTRA5Qt MkgvCfPoU1tJPyFebpTHmg9vnnmV2dC/WDCt3Tl2S/0UWw8pZrM9QNLCIoCeYKqPhdIZ SbMA6Htb/rGuN+oLdVERfqeihgZYIMJXV/pFWmKQfa4srljuXfFuzvBy8XZY60Oj2/WH LleZ2LmmZkBwyZvcAbBz5GqdSiE24kVtWoHbQVwkQI6Poz4GyHfxBSsNjYds0qekZbxp +kDQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Pd1K2PC9; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id qe11-20020a17090b4f8b00b001bfc324fc16si5065504pjb.99.2022.04.06.04.01.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Apr 2022 04:01:25 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Pd1K2PC9; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id F3E9C5B38D9; Wed, 6 Apr 2022 02:24:25 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1383604AbiDEUFC (ORCPT + 99 others); Tue, 5 Apr 2022 16:05:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44580 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241825AbiDEKcm (ORCPT ); Tue, 5 Apr 2022 06:32:42 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 15077DE905; Tue, 5 Apr 2022 03:18:41 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id C17A7B81C9B; Tue, 5 Apr 2022 10:18:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1990CC385A0; Tue, 5 Apr 2022 10:18:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1649153918; bh=sjwe6HTk+VrskoTOBUJ0owPBc/lWtZnBAMxd+IY/hNY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Pd1K2PC9d9lQv119CSeIEQGQX6xUfiv4WLNMiYvVsRt5FA4TpllsD17aJg+gXVJPC njui2zKmKfYJKpJxTdT2bWbo+CIgiClXJ02URShWt9WMWkmvsEuivJXhMJ//2q6v7F RzreOoIFEtTnRlMOa4C9zzVBkqr/PFjzQA5fqrAQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Guillaume Nault , David Ahern , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.10 367/599] ipv4: Fix route lookups when handling ICMP redirects and PMTU updates Date: Tue, 5 Apr 2022 09:31:01 +0200 Message-Id: <20220405070309.752208890@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220405070258.802373272@linuxfoundation.org> References: <20220405070258.802373272@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Guillaume Nault [ Upstream commit 544b4dd568e3b09c1ab38a759d3187e7abda11a0 ] The PMTU update and ICMP redirect helper functions initialise their fl4 variable with either __build_flow_key() or build_sk_flow_key(). These initialisation functions always set ->flowi4_scope with RT_SCOPE_UNIVERSE and might set the ECN bits of ->flowi4_tos. This is not a problem when the route lookup is later done via ip_route_output_key_hash(), which properly clears the ECN bits from ->flowi4_tos and initialises ->flowi4_scope based on the RTO_ONLINK flag. However, some helpers call fib_lookup() directly, without sanitising the tos and scope fields, so the route lookup can fail and, as a result, the ICMP redirect or PMTU update aren't taken into account. Fix this by extracting the ->flowi4_tos and ->flowi4_scope sanitisation code into ip_rt_fix_tos(), then use this function in handlers that call fib_lookup() directly. Note 1: We can't sanitise ->flowi4_tos and ->flowi4_scope in a central place (like __build_flow_key() or flowi4_init_output()), because ip_route_output_key_hash() expects non-sanitised values. When called with sanitised values, it can erroneously overwrite RT_SCOPE_LINK with RT_SCOPE_UNIVERSE in ->flowi4_scope. Therefore we have to be careful to sanitise the values only for those paths that don't call ip_route_output_key_hash(). Note 2: The problem is mostly about sanitising ->flowi4_tos. Having ->flowi4_scope initialised with RT_SCOPE_UNIVERSE instead of RT_SCOPE_LINK probably wasn't really a problem: sockets with the SOCK_LOCALROUTE flag set (those that'd result in RTO_ONLINK being set) normally shouldn't receive ICMP redirects or PMTU updates. Fixes: 4895c771c7f0 ("ipv4: Add FIB nexthop exceptions.") Signed-off-by: Guillaume Nault Reviewed-by: David Ahern Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin --- net/ipv4/route.c | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/net/ipv4/route.c b/net/ipv4/route.c index ce787c386793..c72d0de8bf71 100644 --- a/net/ipv4/route.c +++ b/net/ipv4/route.c @@ -529,6 +529,15 @@ void __ip_select_ident(struct net *net, struct iphdr *iph, int segs) } EXPORT_SYMBOL(__ip_select_ident); +static void ip_rt_fix_tos(struct flowi4 *fl4) +{ + __u8 tos = RT_FL_TOS(fl4); + + fl4->flowi4_tos = tos & IPTOS_RT_MASK; + fl4->flowi4_scope = tos & RTO_ONLINK ? + RT_SCOPE_LINK : RT_SCOPE_UNIVERSE; +} + static void __build_flow_key(const struct net *net, struct flowi4 *fl4, const struct sock *sk, const struct iphdr *iph, @@ -853,6 +862,7 @@ static void ip_do_redirect(struct dst_entry *dst, struct sock *sk, struct sk_buf rt = (struct rtable *) dst; __build_flow_key(net, &fl4, sk, iph, oif, tos, prot, mark, 0); + ip_rt_fix_tos(&fl4); __ip_do_redirect(rt, skb, &fl4, true); } @@ -1077,6 +1087,7 @@ static void ip_rt_update_pmtu(struct dst_entry *dst, struct sock *sk, struct flowi4 fl4; ip_rt_build_flow_key(&fl4, sk, skb); + ip_rt_fix_tos(&fl4); /* Don't make lookup fail for bridged encapsulations */ if (skb && netif_is_any_bridge_port(skb->dev)) @@ -1151,6 +1162,8 @@ void ipv4_sk_update_pmtu(struct sk_buff *skb, struct sock *sk, u32 mtu) goto out; new = true; + } else { + ip_rt_fix_tos(&fl4); } __ip_rt_update_pmtu((struct rtable *)xfrm_dst_path(&rt->dst), &fl4, mtu); @@ -2524,7 +2537,6 @@ static struct rtable *__mkroute_output(const struct fib_result *res, struct rtable *ip_route_output_key_hash(struct net *net, struct flowi4 *fl4, const struct sk_buff *skb) { - __u8 tos = RT_FL_TOS(fl4); struct fib_result res = { .type = RTN_UNSPEC, .fi = NULL, @@ -2534,9 +2546,7 @@ struct rtable *ip_route_output_key_hash(struct net *net, struct flowi4 *fl4, struct rtable *rth; fl4->flowi4_iif = LOOPBACK_IFINDEX; - fl4->flowi4_tos = tos & IPTOS_RT_MASK; - fl4->flowi4_scope = ((tos & RTO_ONLINK) ? - RT_SCOPE_LINK : RT_SCOPE_UNIVERSE); + ip_rt_fix_tos(fl4); rcu_read_lock(); rth = ip_route_output_key_hash_rcu(net, fl4, &res, skb); -- 2.34.1