Received: by 2002:ac0:da4c:0:0:0:0:0 with SMTP id a12csp431019imi; Fri, 22 Jul 2022 02:08:24 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uSiMI46Q5CrHv9tWeGn+aRyGzSDGHkX/tu6isoACZU1IN0Q47qbhmU978mPB4XzwxmVkvT X-Received: by 2002:a17:907:97c8:b0:72b:1cc7:3c4d with SMTP id js8-20020a17090797c800b0072b1cc73c4dmr2300019ejc.217.1658480904106; Fri, 22 Jul 2022 02:08:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658480904; cv=none; d=google.com; s=arc-20160816; b=JzhMDibZrV/R7MWSmqa0OKj2UDcKA9s7gD3FByNH9Pf7q55n7iBl25GSF0aaOSoIEK 1dJ7uj5Q/PujgreoOZCc86xk1e70HHeKlJeLOihSMD+nbqpy8E71GdXwLzWKLjaYzytf padzCQ1abAu2qFLTfW5PbupU2smp4D6Jhm2s+1FykXjpGtJOg8k7l7qmc1CnBvwwQdeE omV09msLnNecy6gIyFJz8yTYDhj5hNG83wAYwosUzlmvI0xIAs3nGLMc+1vJEZp8s5tE icqyrAf9uaXC5U/yqhG9jbnzU/ZjB3P2HSH75VkLiSHn1unfWkuSEYKV6wr/fGh5+vka Xg8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=v/5aGhRoCHpFwV3qQjvwLeTWWInrloa7ON/9UyObNn4=; b=hAg06vviikJHB5dSaEIbvnLi2eQOp5ncfuyobvzjynS5qmbIOcCDHc4GVYOhm9i4UB hX3+0ams8dkPjRfGG2zHFx1Xg4uI/jCMIQqPehffv0jwHXf6epyXIGJpqmbyNcGVQQD+ I12QkQ4tjK/rfHsX98CsjhHf/vAkvKZLhDG03iVlUtOJ6IlKvIT69GQYGOvijI1PI1ei 6C6YYnsXGu2AIwmvREPBIWIS4D9Di8R1I8rxFvinQGmwUwv/HN3PS/HO81vt8AzgbOk9 gcW7LHTH4DiL12xzyAY3gCXs/D2AFz9W3fTDgul43RGF5GRV/FgSWcNWQm4NB62wf8xH OMOQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=MWcTGmD4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m17-20020a056402431100b0043bd231f426si1521960edc.420.2022.07.22.02.07.59; Fri, 22 Jul 2022 02:08:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=MWcTGmD4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229762AbiGVJAT (ORCPT + 99 others); Fri, 22 Jul 2022 05:00:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58450 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230409AbiGVJAR (ORCPT ); Fri, 22 Jul 2022 05:00:17 -0400 Received: from mail-yw1-x112d.google.com (mail-yw1-x112d.google.com [IPv6:2607:f8b0:4864:20::112d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 26009CCC for ; Fri, 22 Jul 2022 02:00:14 -0700 (PDT) Received: by mail-yw1-x112d.google.com with SMTP id 00721157ae682-31e560aa854so40991887b3.6 for ; Fri, 22 Jul 2022 02:00:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v/5aGhRoCHpFwV3qQjvwLeTWWInrloa7ON/9UyObNn4=; b=MWcTGmD4Lx9Tkn9xBtsn+tr4EuHYDuek8ixUxVXKG/QroY3v5SujnvaIyt/2cSewOr SIdK1qzvtsCQzdic/vSqYZDMTw0rXnCsoMB16nUi1H3uLAU1F4f7NINnYD4tKdvOdv2s qUdc6xHkVnzOmaZdWMw9bBOHRcdL5SFfmDD/F2flOTqqhR0/V9N8a8YFykjhZxB/6ka5 ydR429E1KfZ6O/Ecr8Ng1ETKE24IjX9WUW3CF/cMZ5CC1GI1HH8CNXq9l80XZB7aHrLu t5AwszV265/1e+fLhJf1xOYIXqMeZlzTIZ7ygojq7Gz6R3b/0Uo1nnYanzDEd4SROqj+ B/iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=v/5aGhRoCHpFwV3qQjvwLeTWWInrloa7ON/9UyObNn4=; b=ZRYXGVIm3ANa2oFDS5oNkcMywKlwyCR43Ef/cGPz1WnX8LnILP4kdPmCecuduZvIk1 diMtJm+UJPEdPpWx/v/cRR64gQ6wsWTvGZhRWke/GU0NMw8h+og9CFde/chNQRdfsx4u sjLEl3uZEVpUIBtGvatpIZAEe24jYhpQCk8SPe5nispoXHn/Sl+aLHgAhgSHgBTg0Hju ik6nSx9y7rDbEizQTO9HWHQaauHL6GNAISpI7H48vf7+qrevlcTWK7hVM6EC7f0sypT1 CmuRjTNsACRE4hgH/oVD8Oe2FsLyeOYm4zrfop2otooqgFUvFNWMqDOGYMEnFNDU21wY udUQ== X-Gm-Message-State: AJIora+Zrw+40+8bh39n/uyo26NRK5npUJ5oa3rwWg7u+E9RKdmNuYMd PX3pjpPs5yuJ2l1F7PvV2t80Yt6flZ+k1aUuwT+dxA== X-Received: by 2002:a05:690c:730:b0:31e:6237:533e with SMTP id bt16-20020a05690c073000b0031e6237533emr2203648ywb.55.1658480412986; Fri, 22 Jul 2022 02:00:12 -0700 (PDT) MIME-Version: 1.0 References: <20220722074153.2454007-1-william.xuanziyang@huawei.com> In-Reply-To: <20220722074153.2454007-1-william.xuanziyang@huawei.com> From: Eric Dumazet Date: Fri, 22 Jul 2022 11:00:01 +0200 Message-ID: Subject: Re: [net] ipv6/addrconf: fix a null-ptr-deref bug for ip6_ptr To: Ziyang Xuan Cc: David Miller , Hideaki YOSHIFUJI , David Ahern , Jakub Kicinski , Paolo Abeni , netdev , LKML Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=unavailable 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 On Fri, Jul 22, 2022 at 9:42 AM Ziyang Xuan wrote: > > Change net device's MTU to smaller than IPV6_MIN_MTU or unregister > device while matching route. That may trigger null-ptr-deref bug > for ip6_ptr probability as following. > > Reproducer as following: > Firstly, prepare conditions: > $ip netns add ns1 > $ip netns add ns2 > $ip link add veth1 type veth peer name veth2 > $ip link set veth1 netns ns1 > $ip link set veth2 netns ns2 > $ip netns exec ns1 ip -6 addr add 2001:0db8:0:f101::1/64 dev veth1 > $ip netns exec ns2 ip -6 addr add 2001:0db8:0:f101::2/64 dev veth2 > $ip netns exec ns1 ifconfig veth1 up > $ip netns exec ns2 ifconfig veth2 up > $ip netns exec ns1 ip -6 route add 2000::/64 dev veth1 metric 1 > $ip netns exec ns2 ip -6 route add 2001::/64 dev veth2 metric 1 > > Secondly, execute the following two commands in two ssh windows > respectively: > $ip netns exec ns1 sh > $while true; do ip -6 addr add 2001:0db8:0:f101::1/64 dev veth1; ip -6 route add 2000::/64 dev veth1 metric 1; ping6 2000::2; done > > $ip netns exec ns1 sh > $while true; do ip link set veth1 mtu 1000; ip link set veth1 mtu 1500; sleep 5; done > > And in order to increase the probability of reproduce, > we can add mdelay() in find_match() as following: > > static bool find_match(struct fib6_nh *nh, u32 fib6_flags, > if (nh->fib_nh_flags & RTNH_F_DEAD) > goto out; > > + mdelay(1000); But adding a mdelay() in an rcu_read_lock() should not be possible. I guess this means _this_ function is not properly using rcu protection. > if (ip6_ignore_linkdown(nh->fib_nh_dev) && > nh->fib_nh_flags & RTNH_F_LINKDOWN && > !(strict & RT6_LOOKUP_F_IGNORE_LINKSTATE)) > > ========================================================= > BUG: KASAN: null-ptr-deref in find_match.part.0+0x70/0x134 > Read of size 4 at addr 0000000000000308 by task ping6/263 > > CPU: 2 PID: 263 Comm: ping6 Not tainted 5.19.0-rc7+ #14 > Call trace: > dump_backtrace+0x1a8/0x230 > show_stack+0x20/0x70 > dump_stack_lvl+0x68/0x84 > print_report+0xc4/0x120 > kasan_report+0x84/0x120 > __asan_load4+0x94/0xd0 > find_match.part.0+0x70/0x134 > __find_rr_leaf+0x408/0x470 > fib6_table_lookup+0x264/0x540 > ip6_pol_route+0xf4/0x260 > ip6_pol_route_output+0x58/0x70 > fib6_rule_lookup+0x1a8/0x330 > ip6_route_output_flags_noref+0xd8/0x1a0 > ip6_route_output_flags+0x58/0x160 > ip6_dst_lookup_tail+0x5b4/0x85c > ip6_dst_lookup_flow+0x98/0x120 > rawv6_sendmsg+0x49c/0xc70 > inet_sendmsg+0x68/0x94 > sock_sendmsg+0x8c/0xb0 > > It is because ip6_ptr has been assigned to NULL in addrconf_ifdown(), > and ip6_ignore_linkdown() in find_match() accesses ip6_ptr directly. > Although find_match() routine is under rcu_read_lock(), but there is > not synchronize_net() before assign NULL to make rcu grace period end. > This is not how RCU works. > So we can add synchronize_net() before assign ip6_ptr to NULL in > addrconf_ifdown() to fix the null-ptr-deref bug. This does not make sense to me. > > Fixes: 8814c4b53381 ("[IPV6] ADDRCONF: Convert addrconf_lock to RCU.") > Signed-off-by: Ziyang Xuan > --- > net/ipv6/addrconf.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c > index 49cc6587dd77..63d33b29ad21 100644 > --- a/net/ipv6/addrconf.c > +++ b/net/ipv6/addrconf.c > @@ -3757,6 +3757,7 @@ static int addrconf_ifdown(struct net_device *dev, bool unregister) > idev->dead = 1; > > /* protected by rtnl_lock */ > + synchronize_net(); I do not think we want yet another expensive synchronize_net(), especially before setting ip6_ptr to NULL > RCU_INIT_POINTER(dev->ip6_ptr, NULL); > > /* Step 1.5: remove snmp6 entry */ > -- > 2.25.1 >