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_local_in+0x168/0x200
  CPU: 1 UID: 0 PID: 96 Comm: tap_send Not tainted 6.17.0-rc2-dirty #44 PREEMPT(voluntary)
  RIP: 0010:br_nf_local_in+0x168/0x200
  Call Trace:
   <TASK>
   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
   </TASK>
  ---[ 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@huawei.com/
Fixes: 62e7151ae3eb ("netfilter: bridge: confirm multicast packets before passing them up the stack")
Suggested-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Wang Liang <wangliang74@huawei.com>
---
 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_hooks.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;
 	}
 
-	ct = container_of(nfct, struct nf_conn, ct_general);
-	WARN_ON_ONCE(!nf_ct_is_confirmed(ct));
-
 	return ret;
 }
 #endif
-- 
2.33.0

Wang Liang <wangliang74@huawei.com> wrote:
> 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.

I placed this in nf.git:testing.

In case netdev maintainers want to take it directly:

Acked-by: Florian Westphal <fw@strlen.de>

On Fri, 22 Aug 2025 09:50:58 +0200 Florian Westphal wrote:
> Wang Liang <wangliang74@huawei.com> wrote:
> > 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.  
> 
> I placed this in nf.git:testing.

👍️

> In case netdev maintainers want to take it directly:

Unrelated, but while I have you -- nft_flowtable.sh is one of the most
flake-atious test for netdev CI currently :( Could you TAL whenever you
have some spare cycles?

https://netdev.bots.linux.dev/contest.html?test=nft-flowtable-sh

Jakub Kicinski <kuba@kernel.org> wrote:
> Unrelated, but while I have you -- nft_flowtable.sh is one of the most
> flake-atious test for netdev CI currently :( Could you TAL whenever you
> have some spare cycles?

I'll look into it on monday.

Florian Westphal <fw@strlen.de> wrote:
> > flake-atious test for netdev CI currently :( Could you TAL whenever you
> > have some spare cycles?
> 
> I'll look into it on monday.

Sorry, got distracted but I think I see the problem and i expect
to send a fix for this today or tomorrow.

I'll amend the test to deal with this.