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

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

[Cheng Yongkang]

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

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

[Eric Dumazet]

Le jeu. 22 oct. 2026 à 11:04, Cheng Yongkang <teel4res@gmail.com> 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?