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
