Le jeu. 22 oct. 2026 à 11:04, Cheng Yongkang <[email protected]> a écrit : > > Hi all, > > An MRP-aware bridge port can remain in BR_STATE_FORWARDING during > del_nbp(). The terminal br_fdb_delete_by_port() runs before > netdev_rx_handler_unregister(), so a frame received in that window can > learn a new FDB entry whose dst is the port being deleted. No second > FDB sweep follows. The port is then RCU-freed, leaving the FDB entry > with a stale net_bridge_port pointer. > > Observed on Linux v7.3, commit > 08ab31164c55f20c7a2653de3186ae333470e2c1, with KASAN+UBSAN: > > BUG: KASAN: slab-use-after-free in br_forward+0x55/0x3c0 > Read of size 8 > br_forward > br_handle_frame_finish > br_handle_frame > Allocated by: > new_nbp > br_add_if > Freed by: > kfree > kobject_put > rcu_core > > The failing sequence is: > > br_stp_disable_port() leaves the MRP-aware port forwarding > br_mrp_del_impl() restores BR_STATE_FORWARDING > br_fdb_delete_by_port() > ... late ingress frame learns fdb->dst == p ... > netdev_rx_handler_unregister() > call_rcu(&p->rcu, destroy_nbp_rcu) > later frame -> br_forward(stale dst) > > This reproduced in three independent VM boots. The target bridge code > was unchanged. Because the test VM has no driver that accepts > SWITCHDEV_OBJ_ID_MRP, a small diagnostic switchdev endpoint claimed the > MRP object and widened the already-existing post-FDB-flush/pre-unregister > window. It did not replace bridge logic, modify FDB entries, or alter > net_bridge_port lifetime. > > The deletion path should stop new RX processing before the final FDB > sweep, or drain the deferred/FDB state after the RX handler is > unregistered and before queueing the port for RCU free. > > I found no matching upstream fix. Candidate BR-007, BR-040 and BR-058 > are consequences of this same root cause. BR-040 gives the forwarding > window; BR-058 independently describes the stale-FDB lifetime. > > The reproducer, module source, and complete serial logs are available > on request. > > This was found with AI-assisted source analysis and fuzzing; the kernel > behavior above was reproduced under KASAN. > > Thanks, > Cheng Yongkang
I suggest you stop sending these emails, we all have LLM you know. What is the point, if you do not send patches?
