From nobody Fri Sep 5 21:05:17 2025 Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CC9EA275AE1; Fri, 22 Aug 2025 03:51:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.189 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755834716; cv=none; b=N5Zyc6i3smAvwUkrTZTR3oTbUwokI1sFcXwJtAdD3HS8x6leKYmQKblmrbkT+5Eb9j8Ns2e5s+6XD9R3y2wu/aCZOkfM/snuPir7VM/XQjjq//nIYzTuLkYBe4rzqtX/jySW8usJLDhn+ufaFi063qbb+oAawmYs4iFsnnM71BA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755834716; c=relaxed/simple; bh=BNb/Z8MqddmHD2YnZkKSeJS+gvx8ERlrHjU5G4mLYJM=; h=From:To:CC:Subject:Date:Message-ID:MIME-Version:Content-Type; b=VZVIyhFQ/cu4oY9SvgQ1A5OEoA/qxdrKx+Tt+AR4k2FTCh+yi/LummNXttnpG14kMvNLrDFOhOQlcXYByHKMlj7ZKy2t4nIX2BcVTj5RBF64zRVYts7i+LNCDJMfkmltV+6vXWWHihcf0lvjpVLcJFYcZ1FxSEUl3Tkq4tbWol4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=45.249.212.189 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.19.162.254]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4c7R3359X9zdcT6; Fri, 22 Aug 2025 11:47:27 +0800 (CST) Received: from dggpemf500016.china.huawei.com (unknown [7.185.36.197]) by mail.maildlp.com (Postfix) with ESMTPS id 7C0F0180485; Fri, 22 Aug 2025 11:51:51 +0800 (CST) Received: from huawei.com (10.175.104.170) by dggpemf500016.china.huawei.com (7.185.36.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 22 Aug 2025 11:51:50 +0800 From: Wang Liang To: , , , , , , , , , CC: , , , , , , , Subject: [PATCH net v2] netfilter: br_netfilter: do not check confirmed bit in br_nf_local_in() after confirm Date: Fri, 22 Aug 2025 11:52:19 +0800 Message-ID: <20250822035219.3047748-1-wangliang74@huawei.com> X-Mailer: git-send-email 2.33.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems100001.china.huawei.com (7.221.188.238) To dggpemf500016.china.huawei.com (7.185.36.197) Content-Type: text/plain; charset="utf-8" When send a broadcast packet to a tap device, which was added to a bridge, br_nf_local_in() is called to confirm the conntrack. If another conntrack with the same hash value is added to the hash table, which can be triggered by a normal packet to a non-bridge device, the below warning may happen. ------------[ cut here ]------------ WARNING: CPU: 1 PID: 96 at net/bridge/br_netfilter_hooks.c:632 br_nf_loca= l_in+0x168/0x200 CPU: 1 UID: 0 PID: 96 Comm: tap_send Not tainted 6.17.0-rc2-dirty #44 PRE= EMPT(voluntary) RIP: 0010:br_nf_local_in+0x168/0x200 Call Trace: nf_hook_slow+0x3e/0xf0 br_pass_frame_up+0x103/0x180 br_handle_frame_finish+0x2de/0x5b0 br_nf_hook_thresh+0xc0/0x120 br_nf_pre_routing_finish+0x168/0x3a0 br_nf_pre_routing+0x237/0x5e0 br_handle_frame+0x1ec/0x3c0 __netif_receive_skb_core+0x225/0x1210 __netif_receive_skb_one_core+0x37/0xa0 netif_receive_skb+0x36/0x160 tun_get_user+0xa54/0x10c0 tun_chr_write_iter+0x65/0xb0 vfs_write+0x305/0x410 ksys_write+0x60/0xd0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7f ---[ end trace 0000000000000000 ]--- To solve the hash conflict, nf_ct_resolve_clash() try to merge the conntracks, and update skb->_nfct. However, br_nf_local_in() still use the old ct from local variable 'nfct' after confirm(), which leads to this warning. If confirm() does not insert the conntrack entry and return NF_DROP, the warning may also occur. There is no need to reserve the WARN_ON_ONCE, just remove it. Link: https://lore.kernel.org/netdev/20250820043329.2902014-1-wangliang74@h= uawei.com/ Fixes: 62e7151ae3eb ("netfilter: bridge: confirm multicast packets before p= assing them up the stack") Suggested-by: Florian Westphal Signed-off-by: Wang Liang Acked-by: Florian Westphal --- net/bridge/br_netfilter_hooks.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/net/bridge/br_netfilter_hooks.c b/net/bridge/br_netfilter_hook= s.c index 94cbe967d1c1..083e2fe96441 100644 --- a/net/bridge/br_netfilter_hooks.c +++ b/net/bridge/br_netfilter_hooks.c @@ -626,9 +626,6 @@ static unsigned int br_nf_local_in(void *priv, break; } =20 - ct =3D container_of(nfct, struct nf_conn, ct_general); - WARN_ON_ONCE(!nf_ct_is_confirmed(ct)); - return ret; } #endif --=20 2.33.0