Re: [PATCH net] net: bridge: flush FDB again after unregistering the RX handler

[Cheng Yongkang <teel4res@gmail.com>]

Hi Ido,

I'm sorry for not getting back to you on this patch sooner — I only found
your reply when I went through my spam folder.

I tested your suggestion.  I applied exactly the reorder from [1] (move
br_mrp_port_del() and br_cfm_port_del() before br_stp_disable_port()),
and ran the same reproducer: a diagnostic switchdev endpoint keeps
del_nbp() between br_fdb_delete_by_port() and
netdev_rx_handler_unregister() for 1.5 s while a flood keeps sending
frames; the test then waits for destroy_nbp_rcu() and sends frames to the
learned MACs.

On an unpatched v7.3 KASAN kernel the port stays in BR_STATE_FORWARDING,
new entries with dst == the dying port are learned in that window, and
the trigger reports:

  BUG: KASAN: slab-use-after-free in br_forward+0x55/0x3c0
  Read of size 8 at addr ffff8880200bf038 by task mrp-poc/9420
  ...
    br_forward
    br_handle_frame_finish
    br_handle_frame

With the reorder the same window is still exercised in all six cycles
(the 1.5 s hold is reached every time), the port is disabled before the
synchronize_net() and the FDB flush, and there is no KASAN report.  A
normal (non-MRP) bridge regression (two veth pairs in separate netns,
ping, FDB learning, port detach and bridge deletion) also passes.

So the reorder is sufficient and the second flush is not needed.  I have
prepared a v2 implementing it and will send it as a separate patch.

Thanks,
Cheng Yongkang