Received: by 2002:ac0:da4c:0:0:0:0:0 with SMTP id a12csp379922imi; Fri, 22 Jul 2022 00:44:35 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uICxGfmFmOMmEC9UCxZsO+/gGeVF3RL3GTFL8ZM7dGitFH2jspo3TnVhz/+QV8Ljfif6Uh X-Received: by 2002:aa7:93a5:0:b0:51b:e0f8:97a6 with SMTP id x5-20020aa793a5000000b0051be0f897a6mr2446172pff.44.1658475875124; Fri, 22 Jul 2022 00:44:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658475875; cv=none; d=google.com; s=arc-20160816; b=x9431dsWZglzQw9R/gGnI4O8//v/TbDD7PQ6SmYR6Ls7JF4q7RRuUr30u50XaoPEI2 LvNBZgibiezVraOKyyaEGj56JFFqrK6Ri6yVbPNrgwZhB+YW9/EE91nARJIr+kOEpOTE czczVunNnXN2pmY5Qy9iG1PGwP1HJ6tajANQkFDHzWaVfGz3hMak56KNnVlGh2dG0P4k EJpp3rOJuLhM71hB+j/9ROHRqsz8VmufNLYvxwDdMuS5u6YjZmqZJP3dsJNB1gOJZDN1 M3B8nPHD5J5MaEeoetoDwArZR3j9afsC7P7V7yAVlzlpQNqvaMZAtIl0B7lr7m67luAM +W+A== 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 :message-id:date:subject:cc:to:from; bh=hTtYsc3v/jtC6FXWLpmcLtFpi54JLGlaNWlxYODFs/E=; b=TVFBYb6Uk/tlriu7Un8RV+nb0aP6yVqaWw4R8Xtg6yY78qxIeUTxjSPzcmOvP/Agt9 TNkOuz8lnCvqdZNpYOtfVv/RXGB6eYjBhBhc8bzBrkJR3R9CJ1pJza3peaLrRoKKihHV 96IEqN49e+zAre4Y0h1ekKJYw4IBlGISgAIlrEtVblx6+uAMqrq9vo46UwJJWVksMo9k APFLOFceKVn9fbmXLq+ZLFqMGLnXAsdEbeeugxbwHeCsWWbaeiYtTvf+/2anwDTJ+3WO IAJ8mOnBKsGOGoGXOyKXRzFOPq+JkaMQW4uhCnlh1KZBEWMRcMSgQjZn2YVonI3jLxVE 6vmQ== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y4-20020a17090ad70400b001f0c03d481asi4218354pju.138.2022.07.22.00.44.19; Fri, 22 Jul 2022 00:44:35 -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; 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=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234513AbiGVHmG (ORCPT + 99 others); Fri, 22 Jul 2022 03:42:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36324 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234464AbiGVHmD (ORCPT ); Fri, 22 Jul 2022 03:42:03 -0400 Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5D0C417061; Fri, 22 Jul 2022 00:42:01 -0700 (PDT) Received: from canpemm500006.china.huawei.com (unknown [172.30.72.54]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4Lq1ZX55xszGp75; Fri, 22 Jul 2022 15:40:52 +0800 (CST) Received: from ubuntu-82.huawei.com (10.175.104.82) by canpemm500006.china.huawei.com (7.192.105.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Fri, 22 Jul 2022 15:41:57 +0800 From: Ziyang Xuan To: , , , , , , CC: Subject: [net] ipv6/addrconf: fix a null-ptr-deref bug for ip6_ptr Date: Fri, 22 Jul 2022 15:41:53 +0800 Message-ID: <20220722074153.2454007-1-william.xuanziyang@huawei.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.175.104.82] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To canpemm500006.china.huawei.com (7.192.105.130) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham 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 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); 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. So we can add synchronize_net() before assign ip6_ptr to NULL in addrconf_ifdown() to fix the null-ptr-deref bug. 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(); RCU_INIT_POINTER(dev->ip6_ptr, NULL); /* Step 1.5: remove snmp6 entry */ -- 2.25.1