From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CCD22C433F5 for ; Thu, 27 Jan 2022 15:39:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242616AbiA0Pjp (ORCPT ); Thu, 27 Jan 2022 10:39:45 -0500 Received: from new4-smtp.messagingengine.com ([66.111.4.230]:34005 "EHLO new4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237455AbiA0Pjo (ORCPT ); Thu, 27 Jan 2022 10:39:44 -0500 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id 26A1A580EB6; Thu, 27 Jan 2022 10:39:44 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 27 Jan 2022 10:39:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kroah.com; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; bh=WaIfKB6L73BlPeNtlmOZwTQbsqShiIjBr2J2vT exb+o=; b=kjxYAXUPvgtxdi3q7a5Uu7t9LhZ1vnb6czWe6Cr4hHD5TegHDG1Gor GrspqmoX3jRcFlFZwBfcbh/Gp7I29ACZWMweu+DHoT2klDGURHr5gdLcUGwrTfQB Ih5kmBc+DDWRbHO4ANUxga1LbAkU1xYTF/xc1632sgCrCj5qKafP1+wPp6gC6dSq 9f3R8z+enlhWkpe3ibSjZzyWo6vRzrQZdg/AeBefZ20quHUH+jyO+qWl9oBj4SwZ qGbBCc4KCswhs/uBw+YX65lwFm7sxYFDF33hHu1SK06lsBK7ekKv7aFi8HTGdCF+ chVPF+n+ti/6OkGByQtr99T/sC/aQs2g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=WaIfKB6L73BlPeNtl mOZwTQbsqShiIjBr2J2vTexb+o=; b=iOhqajQZ1Rche6XXQ1tGBzf2007JAojWc 3dO+f+Vpj8zAxhPM0r63LPqNXs5DKV5XG9NJFe2xM+R8cJltbHSDpIxiD7OMvXL+ PDk3Taykm2iIOAdu4Qgtoo88myMUNShlh/vLBjpQ9QsCw2vsdrcQtXdjnF9YAhJs gacSk9PaWUfhvWofnU7FjXWhJCA59T+JG1U4E2/wI587ad+BGkLU3u2xmcGmirqD mtowlkNdDypNvogW2y07LyjD5icANqBw0tRJ6zrsEDBSMq9+2hZdUFZBQvxc49Ke EWdrO6QiWiCj1Ot7mzNz41wEZ6EaoSVtmqRLwm7UDiLpaXXqiHJJw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrfeefgdejlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepifhrvghgucfm jfcuoehgrhgvgheskhhrohgrhhdrtghomheqnecuggftrfgrthhtvghrnhepveeuheejgf ffgfeivddukedvkedtleelleeghfeljeeiueeggeevueduudekvdetnecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepghhrvghgsehkrhhorghhrd gtohhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 27 Jan 2022 10:39:42 -0500 (EST) Date: Thu, 27 Jan 2022 16:39:41 +0100 From: Greg KH To: Huang Guobin Cc: nikolay@cumulusnetworks.com, roopa@cumulusnetworks.com, davem@davemloft.net, bridge@lists.linux-foundation.org, netdev@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH 4.19 1/1] net: bridge: clear bridge's private skb space on xmit Message-ID: References: <20220126033639.909340-1-huangguobin4@huawei.com> <20220126033639.909340-2-huangguobin4@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220126033639.909340-2-huangguobin4@huawei.com> Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, Jan 26, 2022 at 11:36:39AM +0800, Huang Guobin wrote: > From: Nikolay Aleksandrov > > [ Upstream commit fd65e5a95d08389444e8591a20538b3edece0e15 ] > > We need to clear all of the bridge private skb variables as they can be > stale due to the packet being recirculated through the stack and then > transmitted through the bridge device. Similar memset is already done on > bridge's input. We've seen cases where proxyarp_replied was 1 on routed > multicast packets transmitted through the bridge to ports with neigh > suppress which were getting dropped. Same thing can in theory happen with > the port isolation bit as well. > > Fixes: 821f1b21cabb ("bridge: add new BR_NEIGH_SUPPRESS port flag to suppress arp and nd flood") > Signed-off-by: Nikolay Aleksandrov > Signed-off-by: David S. Miller > Signed-off-by: Huang Guobin > --- > net/bridge/br_device.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c > index a350c05b7ff5..7c6b1024dd4b 100644 > --- a/net/bridge/br_device.c > +++ b/net/bridge/br_device.c > @@ -42,6 +42,8 @@ netdev_tx_t br_dev_xmit(struct sk_buff *skb, struct net_device *dev) > struct ethhdr *eth; > u16 vid = 0; > > + memset(skb->cb, 0, sizeof(struct br_input_skb_cb)); > + > rcu_read_lock(); > nf_ops = rcu_dereference(nf_br_ops); > if (nf_ops && nf_ops->br_dev_xmit_hook(skb)) { > -- > 2.25.1 > Now queued up, thanks. greg k-h