On Mon, Nov 02, 2026 at 10:25:53AM +0200, Ido Schimmel wrote: > On Sat, Oct 31, 2026 at 09:48:40PM -0700, xiaoblac wrote: > > From: Cheng Yongkang <[email protected]> > > > > del_nbp() flushes the port's FDB entries before it unregisters the RX > > handler. For a normal port, br_stp_disable_port() moves the port to > > BR_STATE_DISABLED before this cleanup. > > > > That does not hold for an MRP ring port. br_set_state() ignores state > > changes while BR_MRP_AWARE_BIT is set, so br_stp_disable_port() leaves > > the port state alone. br_mrp_port_del() then restores forwarding when > > the bridge is up before clearing the bit. A frame received between > > br_fdb_cleanup_by_dst() and netdev_rx_handler_unregister() can therefore > > create a new FDB entry referencing the dying port. Nothing removes that > > entry before destroy_nbp_rcu() frees the port, so a later frame to the > > learned MAC can be forwarded through the freed port. > > > > Remove the MRP and CFM instances before disabling the port, so that > > br_stp_disable_port() actually transitions it to BR_STATE_DISABLED. > > With CONFIG_BRIDGE_VLAN_FILTERING=y, synchronize_net() in > > nbp_vlan_group_unpublish() also drains receive paths that could still > > learn with the old state before the final FDB cleanup. > > > > Found through an LLM-assisted source code analysis workflow and > > reproduced on net with KASAN and CONFIG_BRIDGE_VLAN_FILTERING=y in QEMU. > > A diagnostic switchdev module accepts MRP objects and delays the > > NETDEV_CHANGEUPPER callback for 1.5 s, holding del_nbp() after the FDB > > cleanup and before RX handler removal. The reproducer floods the MRP > > port with rotating source MACs, waits for the port's RCU callback > > through the module's rcu_barrier(), then sends frames to those MACs > > from another port. The unpatched kernel reports: > > > > BUG: KASAN: slab-use-after-free in br_forward+0xb1/0x820 > > Call Trace: > > <IRQ> > > br_forward+0xb1/0x820 > > br_handle_frame_finish+0x148b/0x1e50 > > br_handle_frame+0x90a/0x15c0 > > > > With this patch, three runs of six cycles each reach the delay without > > a KASAN report. > > > > Fixes: 6536993371fa ("bridge: mrp: Integrate MRP into the bridge") > > Suggested-by: Ido Schimmel <[email protected]> > > Link: https://lore.kernel.org/netdev/20261012123051.GA714215@shredder/ > > Closes: > > https://lore.kernel.org/netdev/[email protected]/ > > Signed-off-by: Cheng Yongkang <[email protected]> > > Reviewed-by: Ido Schimmel <[email protected]>
I replied to Sashiko before tagging this patch, but looks like the mail didn't make it to the list. The two issues that it flagged are separate pre-existing issues. The current patch fixes a UAF and doesn't make the situation worse.
