In the Linux kernel, the following vulnerability has been resolved:
net: bridge: mcast: wait for previous gc cycles when removing port
syzbot hit a use-after-free[1] which is caused because the bridge doesn't make sure that all previous garbage has been collected when removing a port. What happens is: CPU 1 CPU 2 start gc cycle remove port acquire gc lock first wait for lock call brmulticasggc() directly acquire lock now but free port the port can be freed while grp timers still running
Make sure all previous gc cycles have finished by using flush_work before freeing the port.
[1] BUG: KASAN: slab-use-after-free in brmulticastportgroupexpired+0x4c0/0x550 net/bridge/br_multicast.c:861 Read of size 8 at addr ffff888071d6d000 by task syz.5.1232/9699
CPU: 1 PID: 9699 Comm: syz.5.1232 Not tainted 6.10.0-rc5-syzkaller-00021-g24ca36a562d6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 Call Trace: <IRQ> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:114 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0xc3/0x620 mm/kasan/report.c:488 kasanreport+0xd9/0x110 mm/kasan/report.c:601 brmulticastportgroupexpired+0x4c0/0x550 net/bridge/brmulticast.c:861 calltimerfn+0x1a3/0x610 kernel/time/timer.c:1792 expiretimers kernel/time/timer.c:1843 [inline] _runtimers+0x74b/0xaf0 kernel/time/timer.c:2417 _runtimerbase kernel/time/timer.c:2428 [inline] _runtimerbase kernel/time/timer.c:2421 [inline] runtimerbase+0x111/0x190 kernel/time/timer.c:2437