Messages in this thread | | | From | "Jason A. Donenfeld" <> | Date | Tue, 23 May 2023 18:42:53 +0200 | Subject | Re: [syzbot] [wireguard?] KASAN: slab-use-after-free Write in enqueue_timer |
| |
On Tue, May 23, 2023 at 6:41 PM Jakub Kicinski <kuba@kernel.org> wrote: > > 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 :(
Worth noting that it could also be caused by adding to a dead timer anywhere in priv_data of another netdev, not just the sole timer_list in net_device.
| |