Messages in this thread | | | Date | Tue, 23 May 2023 09:41:08 -0700 | From | Jakub Kicinski <> | Subject | Re: [syzbot] [wireguard?] KASAN: slab-use-after-free Write in enqueue_timer |
| |
On Tue, 23 May 2023 18:12:32 +0200 Eric Dumazet wrote: > > Your timer had the pleasure of getting queued _after_ a dead watchdog > > timer, no? IOW it tries to update the ->next pointer of a queued > > watchdog timer. We should probably do: > > > > diff --git a/net/core/dev.c b/net/core/dev.c > > index 374d38fb8b9d..f3ed20ebcf5a 100644 > > --- a/net/core/dev.c > > +++ b/net/core/dev.c > > @@ -10389,6 +10389,8 @@ void netdev_run_todo(void) > > WARN_ON(rcu_access_pointer(dev->ip_ptr)); > > WARN_ON(rcu_access_pointer(dev->ip6_ptr)); > > > > + WARN_ON(timer_shutdown_sync(&dev->watchdog_timer)); > > + > > if (dev->priv_destructor) > > dev->priv_destructor(dev); > > if (dev->needs_free_netdev) > > > > to catch how that watchdog_timer is getting queued. Would that make > > sense, Eric? > > Would this case be catched at the time the device is freed ? > > (CONFIG_DEBUG_OBJECTS_FREE=y or something)
It should, no idea why it isn't. Looking thru the code now I don't see any obvious gaps where timer object is on a list but not active :S There's no way to get a vmcore from syzbot, right? :)
Also I thought the shutdown leads to a warning when someone tries to schedule the dead timer but in fact add_timer() just exits cleanly. So the shutdown won't help us find the culprit :(
| |