kernel/git/next/linux-next.git/net/bridge/br_multicast.c, branch stable

net: bridge: mcast: fix use-after-free of a master VLAN's multicast context

2026-08-27T19:35:03+00:00

br_multicast_toggle_one_vlan() clears BR_VLFLAG_MCAST_ENABLED under br->multicast_lock before stopping a VLAN's multicast context. That is the teardown handshake: lockless readers gate on the flag through br_multicast_ctx_should_use() -> br_multicast_ctx_vlan_disabled(), so once it is cleared under the lock no reader can arm the context again. For a master VLAN the handshake never runs. __vlan_del() clears BRIDGE_VLAN_INFO_BRENTRY before calling br_vlan_put_master(), so br_multicast_toggle_one_vlan(masterv, false) returns early on !br_vlan_is_brentry(vlan): the flag stays set and br->multicast_lock is never taken. br_vlan_put_master() then drains the context in br_multicast_ctx_deinit() and frees the VLAN through call_rcu(), while a reader still inside rcu_read_lock() sees the context as enabled and re-arms it. The port and port-VLAN branch of the function has no br_vlan_is_brentry() test and flips the flag under br->multicast_lock, so it is not affected. The reader is the bridge transmit path. For a master VLAN br_multicast_rcv() selects brmctx = &vlan->br_mcast_ctx with pmctx = NULL, so IGMP sent to the bridge device re-arms the context's timers after br_multicast_ctx_deinit() has already stopped them. BUG: KASAN: slab-use-after-free in detach_if_pending+0x412/0x4a0 Write of size 8 at addr ffff88810ac39918 by task brmc/601 __mod_timer+0x51a/0xc50 br_multicast_host_join+0x25b/0x390 __br_multicast_add_group+0x468/0x530 br_ip4_multicast_add_group+0x1a0/0x260 br_multicast_rcv+0x2cda/0x61e0 br_dev_xmit+0x6c4/0x1540 Allocated by task 610: br_vlan_add+0x111/0xb40 br_vlan_info+0x370/0x3e0 Freed by task 0: kfree+0x1a7/0x4f0 rcu_core+0x7dc/0x10a0 Only test br_vlan_is_brentry() when enabling, like the br_multicast_ctx_vlan_global_disabled() test next to it. Disabling then always clears BR_VLFLAG_MCAST_ENABLED under br->multicast_lock before br_multicast_ctx_deinit() drains the context. Fixes: 7b54aaaf53cb ("net: bridge: multicast: add vlan state initialization and control") Cc: stable@vger.kernel.org Signed-off-by: Norbert Szetei Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/D400F6C7-543A-4B79-9E5B-D1D8974DE5C9@doyensec.com Signed-off-by: Jakub Kicinski

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2026-07-30T19:53:19+00:00

Cross-merge networking fixes after downstream PR (net-7.2-rc6). No conflicts. Adjacent changes: net/ipv4/route.c dbc3791e3b24 ("net: do not send ICMP/NDISC Redirects when peer allocation fails") 7804eaa057fe ("ipv4: snapshot dst.dev in ip_rt_send_redirect() and ip_rt_get_source()") drivers/net/tun.c 23dad2d088df ("tun: no longer rely on RTNL in tun_fill_info()") c3da92af07ea ("Revert "tun/tap: add ptr_ring consume helper with netdev queue wakeup"") drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c 3bd438a58e91 ("octeontx2-af: Block VFs from clobbering special CGX PKIND state") 5ba5611ef946 ("octeontx2-af: reserve 4 PKINDs for skip-size custom use") drivers/net/wireless/ath/ath12k/core.h drivers/net/wireless/ath/ath12k/mac.c drivers/net/wireless/ath/ath12k/peer.c 469d7e6077c1 ("wifi: ath12k: resolve PENDING ML peer ID from MLO_PEER_MAP HTT event") 378e659029d5 ("wifi: ath12k: introduce host_alloc_ml_id hardware parameter") c42b27336eef ("wifi: ath12k: fix survey indexing across bands") Signed-off-by: Jakub Kicinski

net: bridge: stop fast-leave after deleting a port group

2026-07-27T22:20:27+00:00

br_multicast_leave_group() iterates mp->ports with pp = &p->next in its fast-leave path. After br_multicast_del_pg() removes p, continuing the loop advances pp through the deleted entry. If multicast-to-unicast was enabled, the bridge can hold multiple port groups for the same port and group with different source MAC addresses. Once multicast-to-unicast is disabled, br_port_group_equal() matches those entries by port only. A fast leave can then delete one entry and continue from its stale next pointer, leaving mp->ports pointing at a deleted port group. Fast leave only needs to remove one matching port group. Break after br_multicast_del_pg() so the loop stops before dereferencing the removed entry. Fixes: 6db6f0eae605 ("bridge: multicast to unicast") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Signed-off-by: Ren Wei Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/1cf0898872ef7c72d5f4c0304414a192c6dac591.1784707712.git.zhilinz@nebusec.ai Signed-off-by: Jakub Kicinski

bridge: mcast: Remove unnecessary argument from br_multicast_alloc_query()

2026-07-21T10:33:46+00:00

After the previous patch, __br_multicast_send_query() no longer relies on br_multicast_alloc_query() to determine the IGMP type of the query. Remove the argument. Reviewed-by: Petr Machata Acked-by: Nikolay Aleksandrov Signed-off-by: Ido Schimmel Link: https://patch.msgid.link/20260708122820.1298718-3-idosch@nvidia.com Signed-off-by: Paolo Abeni

bridge: mcast: Fix a false positive lockdep splat

2026-07-21T10:33:46+00:00

Connecting two bridges on the same system [1] can result in a lockdep splat [2]. The report is a false positive. Multicast queries are built and transmitted under the bridge multicast lock. When the outgoing port of one bridge is configured on top of another bridge, the transmit path re-enters bridge code and acquires the other bridge's multicast lock in order to snoop the query. Both lock instances share a single lockdep class, so lockdep flags the nested acquisition as an AA deadlock. Giving each bridge its own lock class will not solve the problem: the reverse topology would produce an ABBA splat with the same pair of classes. It also consumes a lockdep key per bridge. Instead, fix the problem by deferring the transmission of the queries to a workqueue. Build the skb and update querier state under the lock as before, then enqueue the skb on a per multicast context queue and schedule the work. Purge the queue when the multicast context is de-initialized. At this stage the work cannot be requeued. There is no need to take a reference on skb->dev since the work cannot outlive the bridge or the bridge port. Use the high priority workqueue to reduce the delay between the enqueue time and the transmission time. With default settings (i.e., querier interval - 255 seconds, query interval - 125 seconds) the extra delay should not be a problem. Avoid the unlikely case of the queue growing endlessly by limiting it to 1,000 skbs. Use this number for the simple reason that this is the default Tx queue length. Use local_bh_{disable,enable}() to disable/enable softIRQs and migration in order to avoid corrupting the multicast statistics (per-CPU u64_stats). [1] ip link add name br1 up type bridge mcast_snooping 1 mcast_querier 1 ip link add name br0 up type bridge mcast_snooping 1 mcast_querier 1 ip link add link br0 name br0.10 up master br1 type vlan id 10 [2] WARNING: possible recursive locking detected 7.0.0-virtme-gb50c64a58a90 #1 Not tainted [...] ip/339 is trying to acquire lock: ffff888104f0b480 (&br->multicast_lock){+.-.}-{3:3}, at: br_ip6_multicast_query (net/bridge/br_multicast.c:3584) but task is already holding lock: ffff888104f03480 (&br->multicast_lock){+.-.}-{3:3}, at: br_multicast_port_query_expired (net/bridge/br_multicast.c:1904) [...] Call Trace: [...] br_ip6_multicast_query (net/bridge/br_multicast.c:3584) br_multicast_ipv6_rcv (net/bridge/br_multicast.c:3988) br_dev_xmit (net/bridge/br_device.c:98 (discriminator 1)) dev_hard_start_xmit (net/core/dev.c:3904) __dev_queue_xmit (net/core/dev.c:4871) vlan_dev_hard_start_xmit (net/8021q/vlan_dev.c:131 (discriminator 1)) dev_hard_start_xmit (net/core/dev.c:3904) __dev_queue_xmit (net/core/dev.c:4871) br_dev_queue_push_xmit (net/bridge/br_forward.c:60) __br_multicast_send_query (net/bridge/br_multicast.c:1811 (discriminator 1)) br_multicast_send_query (net/bridge/br_multicast.c:1889) br_multicast_port_query_expired (net/bridge/br_multicast.c:1914) call_timer_fn (kernel/time/timer.c:1749) [...] Reported-by: syzbot+d7b7f1412c02134efa6d@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/000000000000c4c9d405f2643e01@google.com/ Reviewed-by: Petr Machata Acked-by: Nikolay Aleksandrov Signed-off-by: Ido Schimmel Link: https://patch.msgid.link/20260708122820.1298718-2-idosch@nvidia.com Signed-off-by: Paolo Abeni

net: bridge: use atomic ops to read/change p->flags (III)

2026-06-13T01:03:46+00:00

Use test_bit(), clear_bit(), set_bit() in: net/bridge/br_multicast.c net/bridge/br_netlink.c net/bridge/br_stp.c net/bridge/br_stp_bpdu.c net/bridge/br_switchdev.c net/bridge/br_vlan_options.c Signed-off-by: Eric Dumazet Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260611203453.3067462-6-edumazet@google.com Signed-off-by: Jakub Kicinski

bridge: mcast: Synchronously shutdown port multicast timers

2026-06-05T01:11:54+00:00

Currently, while four timers are set up during port multicast context initialization, only two are synchronously deleted when the context is de-initialized, just before being deleted. This is fine because the structure containing the multicast context (either a bridge port or a VLAN) is only deleted after an RCU grace period and it will not pass as long as the timers are executing. These timers are also not supposed to do any work at this stage. They acquire the bridge multicast lock, see that the multicast context was disabled and exit. Make the code more explicit and symmetric and synchronously shutdown all four timers when the multicast context is de-initialized. Use timer_shutdown_sync() to guarantee that the timers will not be re-armed given that the containing structure is being deleted. Acked-by: Nikolay Aleksandrov Signed-off-by: Ido Schimmel Link: https://patch.msgid.link/20260603103522.622411-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2026-05-21T22:09:02+00:00

Cross-merge networking fixes after downstream PR (net-7.1-rc5). No conflicts, adjacent changes: drivers/net/ethernet/mellanox/mlx5/core/en_txrx.c cc199cd1b912 ("net/mlx5e: Reduce branches in napi poll") c326f9c68921 ("net/mlx5e: xsk: Fix unlocked writing to ICOSQ") drivers/net/ethernet/mellanox/mlx5/core/eswitch.c c6df9a65cbb0 ("net/mlx5: Skip disabled vports when setting max TX speed") 1fba57c91416 ("net/mlx5: Add VHCA_ID page management mode support") net/mac80211/mlme.c a6e6ccd5bd07 ("wifi: mac80211: consume only present negotiated TTLM maps") 49e62ec6eb06 ("wifi: mac80211: move frame RX handling to type files") Signed-off-by: Jakub Kicinski

net: bridge: remove stale rcu_barrier() in br_multicast_dev_del()

2026-05-21T02:05:50+00:00

This rcu_barrier() came from a time call_rcu() calls were used in net/bridge/br_multicast.c. Now kfree_rcu() is there, we can remove this problematic rcu_barrier() which causes extreme RTNL pressure in many syzbot reports. INFO: task syz-executor:77945 is blocked on a mutex likely owned by task kworker/u1024:5:36537. task:kworker/u1024:5 state:D stack:24616 pid:36537 tgid:36537 ppid:2 task_flags:0x4208060 flags:0x00080000 last_sleep:612797637337 Workqueue: netns cleanup_net Call Trace: [] context_switch+0xf2a/0x1730 kernel/sched/core.c:6483 [] __schedule+0x1133/0x43a0 kernel/sched/core.c:8411 [] __schedule_loop kernel/sched/core.c:8514 [inline] [] schedule+0xab/0x260 kernel/sched/core.c:8529 [] schedule_timeout+0xc3/0x2b0 kernel/time/sleep_timeout.c:75 [] do_wait_for_common kernel/sched/completion.c:100 [inline] [] __wait_for_common kernel/sched/completion.c:121 [inline] [] wait_for_common kernel/sched/completion.c:132 [inline] [] wait_for_completion+0x2c7/0x5d0 kernel/sched/completion.c:153 [] rcu_barrier+0x49f/0x620 kernel/rcu/tree.c:3888 [] br_multicast_dev_del+0x303/0x350 net/bridge/br_multicast.c:4459 [] br_dev_uninit+0x1c/0x40 net/bridge/br_device.c:157 [] unregister_netdevice_many_notify+0x1c1c/0x2300 net/core/dev.c:12599 [] ops_exit_rtnl_list net/core/net_namespace.c:187 [inline] [] ops_undo_list+0x3d3/0x940 net/core/net_namespace.c:248 Signed-off-by: Eric Dumazet Reviewed-by: Jakub Sitnicki Reviewed-by: Ido Schimmel Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260519095540.2643318-1-edumazet@google.com Signed-off-by: Jakub Kicinski

bridge: mcast: Fix a possible use-after-free when removing a bridge port

2026-05-20T01:15:22+00:00

When per-VLAN multicast snooping is enabled, the bridge iterates over all the bridge ports, disables the per-port multicast context on each port and enables the per-{port, VLAN} multicast contexts instead. The reverse happens when per-VLAN multicast snooping is disabled. When global multicast snooping is enabled, the bridge iterates over all the bridge ports and enables the per-port multicast context on each port. The reverse happens when multicast snooping is disabled. The above scheme can result in a situation where both types of contexts (per-port and per-{port, VLAN}) are enabled on a single bridge port: # ip link add name br1 up type bridge mcast_snooping 1 mcast_querier 1 vlan_filtering 1 # ip link add name dummy1 up master br1 type dummy # ip link set dev br1 type bridge mcast_vlan_snooping 1 # ip link set dev br1 type bridge mcast_snooping 0 # ip link set dev br1 type bridge mcast_snooping 1 This is not intended and it is a problem since the commit cited below. Prior to this commit, when removing a bridge port, br_multicast_disable_port() would disable the per-port multicast context and the per-{port, VLAN} multicast contexts would get disabled when flushing VLANs. After this commit, br_multicast_disable_port() only disables the per-port multicast context if per-VLAN multicast snooping is disabled. If both types of contexts were enabled on the port when it was removed, the per-port multicast context would remain enabled when freeing the bridge port, leading to a use-after-free [1]. Fix by preventing the bridge from enabling / disabling the per-port multicast contexts when toggling global multicast snooping if per-VLAN multicast snooping is enabled. [1] ODEBUG: free active (active state 0) object: ffff88810f8bda78 object type: timer_list hint: br_ip6_multicast_port_query_expired (net/bridge/br_multicast.c:1927) WARNING: lib/debugobjects.c:629 at debug_print_object+0x1b1/0x3e0, CPU#5: swapper/5/0 [...] Call Trace: __debug_check_no_obj_freed (lib/debugobjects.c:1116) kfree (mm/slub.c:2620 mm/slub.c:6250 mm/slub.c:6565) kobject_cleanup (lib/kobject.c:689) rcu_do_batch (kernel/rcu/tree.c:2617) rcu_core (kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) __irq_exit_rcu (kernel/softirq.c:656 kernel/softirq.c:496 kernel/softirq.c:735) irq_exit_rcu (kernel/softirq.c:752) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1061 (discriminator 47) arch/x86/kernel/apic/apic.c:1061 (discriminator 47)) Fixes: 4b30ae9adb04 ("net: bridge: mcast: re-implement br_multicast_{enable, disable}_port functions") Reported-by: syzbot+ae231e0552fa77b26ea1@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/87qznowlfs.ffs@tglx/ Reported-by: Thomas Gleixner Acked-by: Nikolay Aleksandrov Signed-off-by: Ido Schimmel Link: https://patch.msgid.link/20260517121122.188333-2-idosch@nvidia.com Signed-off-by: Jakub Kicinski