Re: [PATCH net-next v2] ipv4: igmp: remove multicast group from hash table on device destruction

[Yuyang Huang]

On Wed, Jul 1, 2026 at 6:15 AM Kuniyuki Iwashima <kuniyu@xxxxxxxxxx> wrote:
>
> From: Ido Schimmel <idosch@xxxxxxxxxx>
> Date: Tue, 30 Jun 2026 19:59:34 +0300
> > On Tue, Jun 30, 2026 at 04:55:22PM +0900, Yuyang Huang wrote:
> > > > Hi,
> > > >
> > > > why sending this to net-next not to net if that's a bug fix?
> > > >
> > > > In the v1 thread it was said
> > > > >This is a long-standing bug, not a recent regression.
> > > >
> > > > so why do not cc stable kernel to get rid of this bug from
> > > > stable kernels in such case?
> > >
> > > Thanks for the advise, will send this patch to stable kernel.
> >
> > Please target v3 at net and add a trace given you're claiming for a
> > use-after-free. That way we know that the problem is real and not a
> > false-positive from some tool. You can reproduce it by adding enough
> > delay in inetdev_destroy():
>
> I guess delay was added between ip_mc_destroy_dev() and
> RCU_INIT_POINTER(dev->ip_ptr, NULL) ?
>
> I feel like we should clear it first and destroy everything
> as done in IPv6 addrconf_ifdown().
>
>
> >
> > BUG: KASAN: slab-use-after-free in ip_check_mc_rcu+0x2cc/0x500
> > Read of size 4 at addr ffff88810c571208 by task mausezahn/419
> >
> > CPU: 2 UID: 0 PID: 419 Comm: mausezahn Not tainted 7.1.0-virtme-g15d4a7c23bf6 #17 PREEMPT(lazy)
> > Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> > Call Trace:
> >  <IRQ>
> >  dump_stack_lvl+0x4d/0x70
> >  print_report+0x153/0x4c2
> >  kasan_report+0xda/0x110
> >  ip_check_mc_rcu+0x2cc/0x500
> >  ip_route_input_rcu.part.0+0x13d/0xbc0
> >  ip_route_input_noref+0xb6/0x110
> >  ip_rcv_finish_core+0x41b/0x1d90
> >  ip_rcv_finish+0xea/0x1b0
> >  ip_rcv+0xb7/0x1b0
> >  __netif_receive_skb_one_core+0xfc/0x180
> >  process_backlog+0x1ea/0x5e0
> >  __napi_poll+0x97/0x480
> >  net_rx_action+0x97c/0xfa0
> >  handle_softirqs+0x18c/0x4f0
> >  do_softirq+0x42/0x60
> >  </IRQ>
> >

Thanks for the advise, I will try to add a trace in v3. For more
reference, the issue is pointed out in the following discussion:

https://lore.kernel.org/netdev/95adff35-ee56-49d3-8567-382ac17810b3@xxxxxxxxxx/#t