Hi all, When a DSA LAG member joins a bond that is already present in br->port_list, nbp_switchdev_hwdom_set() can iterate over the joining port itself. The self-match leaves hwdom at the unassigned sentinel 0 while the port is marked offloaded and tx_fwd_offload is enabled. No busy_hwdoms bit is reserved.
DSA frames may still carry offload_fwd_mark. If another port also has hwdom 0, nbp_switchdev_allowed_egress() treats the two ports as the same hardware domain, so an otherwise valid forwarded frame is suppressed at bridge egress. Observed on Linux v7.3, commit 08ab31164c55f20c7a2653de3186ae333470e2c1. The exact DSA LAG route ran: dsa_port_lag_join dsa_port_bridge_join switchdev_bridge_port_offload After the join: offload_count=1 hwdom=0 busy_hwdoms=0 tx_fwd_offload=1 With a second port using a different switch parent ID and also left at hwdom 0: unmarked control frame: delivered 8/8 identical frame with offload_fwd_mark=1: delivered 0/8 The result repeated with two independent netdevsim switch IDs. There was no KASAN report, oops, or panic; the defect is packet suppression. The target bridge and DSA core code were unchanged. The test VM has no physical DSA driver, so an in-tree dsa_loop build was exposed as an external module with only port_lag_join/port_lag_leave and tx_fwd_offload behavior. A diagnostic hook set the same offload_fwd_mark bit a hardware switch would set. hwdom allocation must exclude the joining port, or publication must occur only after a nonzero domain is reserved. Candidate BR-031 is a different error-path leak in the same bridge switchdev code, not a duplicate of this packet path. I found no matching self-match allocation fix. A 2024 generic offload_fwd_mark/hwdom-0 comparison patch is also absent from the target source, but that patch does not fix the unassigned-domain state created here. The module sources, PoC, and full logs are available on request. This was found with AI-assisted source analysis and fuzzing; the packet-drop differential was reproduced in QEMU. Thanks, Cheng Yongkang
