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...
