[BUG] net: bridge: late FDB learning can outlive an MRP port

[Cheng Yongkang <teel4res@gmail.com>]

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