On Tue, Feb 16, 2021 at 7:15 PM Dmitry Vyukov <dvyu...@google.com> wrote: > > On Tue, Feb 16, 2021 at 06:50:20PM +0100, Jason A. Donenfeld wrote: > > > On Tue, Feb 16, 2021 at 6:46 PM Jason A. Donenfeld <ja...@zx2c4.com> > > > wrote: > > > > On Tue, Feb 16, 2021 at 6:28 PM Catalin Marinas > > > > <catalin.mari...@arm.com> wrote: > > > > > > hlist_add_head include/linux/list.h:883 [inline] > > > > > > enqueue_timer+0x18/0xc0 kernel/time/timer.c:581 > > > > > > mod_timer+0x14/0x20 kernel/time/timer.c:1106 > > > > > > mod_peer_timer drivers/net/wireguard/timers.c:37 [inline] > > > > > > wg_timers_any_authenticated_packet_traversal+0x68/0x90 > > > > > > drivers/net/wireguard/timers.c:215 > > > > > > > > The line of hlist_add_head that it's hitting is: > > > > > > > > static inline void hlist_add_head(struct hlist_node *n, struct > > > > hlist_head *h) > > > > { > > > > struct hlist_node *first = h->first; > > > > WRITE_ONCE(n->next, first); > > > > if (first) > > > > > > > > So that means it's the dereferencing of h that's a problem. That comes > > > > from: > > > > > > > > static void enqueue_timer(struct timer_base *base, struct timer_list > > > > *timer, > > > > unsigned int idx, unsigned long bucket_expiry) > > > > { > > > > > > > > hlist_add_head(&timer->entry, base->vectors + idx); > > > > > > > > That means it concerns base->vectors + idx, not the timer_list object > > > > that wireguard manages. That's confusing. Could that imply that the > > > > bug is in freeing a previous timer without removing it from the timer > > > > lists, so that it winds up being in base->vectors? > > > > Good point, it's indeed likely that the timer list is messed up already, > > just an unlucky encounter in the wireguard code. > > > > > Digging around on syzkaller, it looks like there's a similar bug on > > > jbd2, concerning iptunnels's allocation: > > > > > > https://syzkaller.appspot.com/text?tag=CrashReport&x=13afb19cd00000 > > [...] > > > It might not actually be a wireguard bug? > > > > I wonder whether syzbot reported similar issues with > > CONFIG_KASAN_SW_TAGS. It shouldn't be that different from the HW_TAGS > > but at least we can rule out qemu bugs with the MTE emulation. > > +Eric
I've seen some similar reports on other syzkaller instances. They all have similar alloc/free stacks, but different access stacks. This does not seem to be wireguard nor arm/mte related. It seems that something released the device prematurely, and then some innocent code gets a use-after-free.