Received: by 2002:a05:6a10:7420:0:0:0:0 with SMTP id hk32csp582302pxb; Tue, 15 Feb 2022 22:50:02 -0800 (PST) X-Google-Smtp-Source: ABdhPJwHuQ1APQMYf0F8mmwG+H+wTbPo671BclJ23S5YHpdYPc1zz7O6nQCTuRsYlDSorym2I2pw X-Received: by 2002:a65:4d4f:0:b0:372:a6e1:f675 with SMTP id j15-20020a654d4f000000b00372a6e1f675mr1181820pgt.112.1644994201847; Tue, 15 Feb 2022 22:50:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644994201; cv=none; d=google.com; s=arc-20160816; b=kzzuTP4+c30Df2Mw8BddSvJwPksWUtlzjI8s7zzBYI1veC3iaaHsxlTHo1WMKrmASC XlQHTyBWN4l9bNqLAbVjkQOQPH+ymnLJ/2W3AI/CLVsyNkS0MWsh7m62koj8/37VCk// G+pgwNypnKRN2mzeKpGOJSlU0IHS4odwhoWyHZkOEP4i0av2Dm/TvOu58QT79k1dwF6p qT7hIa2x89FszvWG3DgMcJKshxWKICMHBuCD8jAY/eBn3wIkvRMdvB24L0MbCi7+NQR/ +A7AgEUGZHkPi4rym4IFEwBrHZ+oqkXVqU38WzLeMWmq0/zvw2aY0O6wbMyFMuJdKEI5 nbog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=m2KAr6r5oHS0uR2T86jAv+46LmLNSv3F9a+KZI9pFxA=; b=sFmpZltRyJgZIu+mAKs5uU85YWWKFJ3GDrWt5kfBObKu4xa3HiOjKHSrk9zd3eFe0F phjnhlRjkmcGbjcKQi8B9jqJCVQvPpUuaPSUh0bRFJABBSFuTWNq6Dqw6Vgm4RelaRcr TyWKhAOb6go5zSxowpZhww09fBsXf9BHkbSOZH4Sc1sp/fehDZ/xO99VWcDshBe7Ddb8 PKmlpX7KsQl7TufEtgz/41UHpfC89tgXZJet/2eK5bcuomgfjP28yMSnWw1+KtJb3nLZ jrakRxajs3vpW4MwRWc/HjOlI8opw8WYp1VPSrWrfiE+osz74RhfWo7RoGSBdnqrlD3r jdwQ== 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:18 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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id b7si32386750pff.301.2022.02.15.22.50.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Feb 2022 22:50:01 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id CDE1421EC28; Tue, 15 Feb 2022 22:36:09 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344193AbiBPDTR (ORCPT + 99 others); Tue, 15 Feb 2022 22:19:17 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:43660 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233625AbiBPDTQ (ORCPT ); Tue, 15 Feb 2022 22:19:16 -0500 Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 69FB7DCE07; Tue, 15 Feb 2022 19:19:05 -0800 (PST) Received: from kwepemi100022.china.huawei.com (unknown [172.30.72.54]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4Jz34c1SV7z8wfW; Wed, 16 Feb 2022 11:15:44 +0800 (CST) Received: from kwepemm600001.china.huawei.com (7.193.23.3) by kwepemi100022.china.huawei.com (7.221.188.126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Wed, 16 Feb 2022 11:19:03 +0800 Received: from [10.174.176.245] (10.174.176.245) by kwepemm600001.china.huawei.com (7.193.23.3) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Wed, 16 Feb 2022 11:19:02 +0800 Subject: Re: [BUG] net: ipv4: The sent udp broadcast message may be converted to an arp request message To: Ido Schimmel CC: David Miller , Jakub Kicinski , , , , , linux-kernel References: <55a04a8f-56f3-f73c-2aea-2195923f09d1@huawei.com> From: "wanghai (M)" Message-ID: Date: Wed, 16 Feb 2022 11:19:01 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.176.245] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To kwepemm600001.china.huawei.com (7.193.23.3) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, 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 在 2022/2/8 15:51, Ido Schimmel 写道: > On Mon, Feb 07, 2022 at 10:09:49PM +0800, wanghai (M) wrote: >> Hello, >> >> I found a bug, but I don't know how to fix it. Anyone have some good ideas? >> >> This bug will cause udp broadcast messages not to be sent, but instead send >> non-expected arp request messages. >> >> Deleting the ip while sending udp broadcast messages and then configuring >> the ip again will probably trigger the bug. >> >> The following is the timing diagram of the bug, cpu0 sends a broadcast >> message and cpu1 deletes the routing table at the appropriate time. >> >> cpu0                                        cpu1 >> send() >>   udp_sendmsg() >>     ip_route_output_flow() >>     |  fib_lookup() >>     udp_send_skb() >>       ip_send_skb() >>         ip_finish_output2() >> >>                                             ifconfig eth0:2 down >>                                               fib_del_ifaddr >>                                                 fib_table_delete // delete >> fib table >> >>           ip_neigh_for_gw() >>           |  ip_neigh_gw4() >>           |    __ipv4_neigh_lookup_noref() >>           |    __neigh_create() >>           |      tbl->constructor(n) --> arp_constructor() >>           |        neigh->type = inet_addr_type_dev_table(); // no route, >> neigh->type = RTN_UNICAST >>           neigh_output() // unicast, send an arp request and create an >> exception arp entry >> >> After the above operation, an abnormal arp entry will be generated. If >> the ip is configured again(ifconfig eth0:2 12.0.208.0), the abnormal arp >> entry will still exist, and the udp broadcast message will be converted >> to an arp request message when it is sent. > Can you try the below? Not really happy with it, but don't have a better > idea at the moment. It seemed better to handle it from the control path > than augmenting the data path with more checks > > diff --git a/include/net/arp.h b/include/net/arp.h > index 031374ac2f22..9e6a1961b64c 100644 > --- a/include/net/arp.h > +++ b/include/net/arp.h > @@ -64,6 +64,7 @@ void arp_send(int type, int ptype, __be32 dest_ip, > const unsigned char *dest_hw, > const unsigned char *src_hw, const unsigned char *th); > int arp_mc_map(__be32 addr, u8 *haddr, struct net_device *dev, int dir); > +int arp_invalidate(struct net_device *dev, __be32 ip); > void arp_ifdown(struct net_device *dev); > > struct sk_buff *arp_create(int type, int ptype, __be32 dest_ip, > diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c > index 4db0325f6e1a..b81665ce2b57 100644 > --- a/net/ipv4/arp.c > +++ b/net/ipv4/arp.c > @@ -1116,7 +1116,7 @@ static int arp_req_get(struct arpreq *r, struct net_device *dev) > return err; > } > > -static int arp_invalidate(struct net_device *dev, __be32 ip) > +int arp_invalidate(struct net_device *dev, __be32 ip) > { > struct neighbour *neigh = neigh_lookup(&arp_tbl, &ip, dev); > int err = -ENXIO; > diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c > index 4d61ddd8a0ec..2d7085232cb5 100644 > --- a/net/ipv4/fib_frontend.c > +++ b/net/ipv4/fib_frontend.c > @@ -1112,9 +1112,11 @@ void fib_add_ifaddr(struct in_ifaddr *ifa) > return; > > /* Add broadcast address, if it is explicitly assigned. */ > - if (ifa->ifa_broadcast && ifa->ifa_broadcast != htonl(0xFFFFFFFF)) > + if (ifa->ifa_broadcast && ifa->ifa_broadcast != htonl(0xFFFFFFFF)) { > fib_magic(RTM_NEWROUTE, RTN_BROADCAST, ifa->ifa_broadcast, 32, > prim, 0); > + arp_invalidate(dev, ifa->ifa_broadcast); > + } > > if (!ipv4_is_zeronet(prefix) && !(ifa->ifa_flags & IFA_F_SECONDARY) && > (prefix != addr || ifa->ifa_prefixlen < 32)) { > @@ -1128,6 +1130,7 @@ void fib_add_ifaddr(struct in_ifaddr *ifa) > if (ifa->ifa_prefixlen < 31) { > fib_magic(RTM_NEWROUTE, RTN_BROADCAST, prefix | ~mask, > 32, prim, 0); > + arp_invalidate(dev, prefix | ~mask); > } > } > } > . Hi, Schimmel. can you push this patch to the linux.git tree please? > -- Wang Hai