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
