On Thu, May 07, 2026 at 08:30:10PM +0300, Ido Schimmel wrote: > On Thu, May 07, 2026 at 10:57:04AM +0200, Thomas Gleixner wrote: > > On Wed, May 06 2026 at 18:29, Thomas Gleixner wrote: > > > On Mon, May 04 2026 at 05:23, syzbot wrote: > > >> > > >> ------------[ cut here ]------------ > > >> ODEBUG: free active (active state 0) object: ffff888033a47278 object > > >> type: timer_list hint: br_ip6_multicast_port_query_expired+0x0/0x380 > > >> net/bridge/br_multicast.c:-1 > > > > > > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > An object which contains an active timer is RCU freed.... > > > > Unlike the other timer in the same object, the own_query timer is not > > shut down in br_multicast_port_ctx_deinit() > > > > Something kike the below. > > > > Thanks, > > > > tglx > > --- > > --- a/net/bridge/br_multicast.c > > +++ b/net/bridge/br_multicast.c > > @@ -2030,8 +2030,10 @@ void br_multicast_port_ctx_deinit(struct > > > > #if IS_ENABLED(CONFIG_IPV6) > > timer_delete_sync(&pmctx->ip6_mc_router_timer); > > + timer_delete_sync(&pmctx->ip6_own_query_timer); > > #endif > > timer_delete_sync(&pmctx->ip4_mc_router_timer); > > + timer_delete_sync(&pmctx->ip4_own_query_timer); > > > > spin_lock_bh(&br->multicast_lock); > > del |= br_ip6_multicast_rport_del(pmctx); > > Thanks for the report and the fix. It looks correct, but it's unclear to > me which commit to blame. > > AFAICT, the trace tells us that the timer is pending (not executing) > when the object that contains it is RCU freed. However, it shouldn't be > possible for the timer to be pending at this stage since it is > deactivated when the port multicast context is disabled and it is only > reactivated if the context is not disabled. > > So, I see two options: > > 1. We did not disable port multicast context. > > 2. We did disable the port multicast context, but the timer somehow got > reactivated. > > I will look into it...
FYI, I found the problem (and a reproducer). I will try to send a fix later this week
