On Tue, May 23, 2023 at 07:16:20PM +0200, Jason A. Donenfeld wrote:
> On Tue, May 23, 2023 at 06:47:41PM +0200, Jason A. Donenfeld wrote:
> > On Tue, May 23, 2023 at 6:46 PM Jakub Kicinski wrote:
> > >
> > > On Tue, 23 May 2023 18:14:18 +0200 Jason A. Donenfeld wrote:
> > > > So, IOW, not a wiregu
On Tue, May 23, 2023 at 06:47:41PM +0200, Jason A. Donenfeld wrote:
> On Tue, May 23, 2023 at 6:46 PM Jakub Kicinski wrote:
> >
> > On Tue, 23 May 2023 18:14:18 +0200 Jason A. Donenfeld wrote:
> > > So, IOW, not a wireguard bug, right?
> >
> > What's slightly concerning is that there aren't any ot
On Tue, May 23, 2023 at 7:05 PM Eric Dumazet wrote:
>
> On Tue, May 23, 2023 at 7:01 PM Jason A. Donenfeld wrote:
> >
> > On Tue, May 23, 2023 at 09:47:36AM -0700, Jakub Kicinski wrote:
> > > On Tue, 23 May 2023 18:42:53 +0200 Jason A. Donenfeld wrote:
> > > > > It should, no idea why it isn't. L
On Tue, May 23, 2023 at 7:01 PM Jason A. Donenfeld wrote:
>
> On Tue, May 23, 2023 at 09:47:36AM -0700, Jakub Kicinski wrote:
> > On Tue, 23 May 2023 18:42:53 +0200 Jason A. Donenfeld wrote:
> > > > It should, no idea why it isn't. Looking thru the code now I don't see
> > > > any obvious gaps whe
On Tue, May 23, 2023 at 09:47:36AM -0700, Jakub Kicinski wrote:
> On Tue, 23 May 2023 18:42:53 +0200 Jason A. Donenfeld wrote:
> > > 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 t
On Tue, 23 May 2023 18:42:53 +0200 Jason A. Donenfeld wrote:
> > 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 shutdow
On Tue, May 23, 2023 at 6:46 PM Jakub Kicinski wrote:
>
> On Tue, 23 May 2023 18:14:18 +0200 Jason A. Donenfeld wrote:
> > So, IOW, not a wireguard bug, right?
>
> What's slightly concerning is that there aren't any other timers
> leading to
>
> KASAN: slab-use-after-free Write in enqueue_timer
On Tue, 23 May 2023 18:14:18 +0200 Jason A. Donenfeld wrote:
> So, IOW, not a wireguard bug, right?
What's slightly concerning is that there aren't any other timers
leading to
KASAN: slab-use-after-free Write in enqueue_timer
:( If WG was just an innocent bystander there should be, right?
On Tue, May 23, 2023 at 6:41 PM Jakub Kicinski 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 probab
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
> > i
On Tue, May 23, 2023 at 09:05:12AM -0700, Jakub Kicinski wrote:
> On Tue, 23 May 2023 17:46:20 +0200 Jason A. Donenfeld wrote:
> > > Freed by task 41:
> > > __kmem_cache_free+0x264/0x3c0 mm/slub.c:3799
> > > device_release+0x95/0x1c0
> > > kobject_cleanup lib/kobject.c:683 [inline]
> > > kobjec
On Tue, May 23, 2023 at 6:05 PM Jakub Kicinski wrote:
>
> On Tue, 23 May 2023 17:46:20 +0200 Jason A. Donenfeld wrote:
> > > Freed by task 41:
> > > __kmem_cache_free+0x264/0x3c0 mm/slub.c:3799
> > > device_release+0x95/0x1c0
> > > kobject_cleanup lib/kobject.c:683 [inline]
> > > kobject_relea
On Tue, 23 May 2023 17:46:20 +0200 Jason A. Donenfeld wrote:
> > Freed by task 41:
> > __kmem_cache_free+0x264/0x3c0 mm/slub.c:3799
> > device_release+0x95/0x1c0
> > kobject_cleanup lib/kobject.c:683 [inline]
> > kobject_release lib/kobject.c:714 [inline]
> > kref_put include/linux/kref.h:65 [
Hi!
I already asked about this on https://web.libera.chat/#wireguard and was told
to post to the mailing list.
tl;dr: under windows when using multiple subnets different from /0 or /32, they
are treated as networks with broadcast adresses, makeing certain addresses not
be tunneled as expecte
Hey Syzkaller & Netdev folks,
I've been looking at this a bit and am slightly puzzled. At first I saw
this:
> enqueue_timer+0xad/0x560 kernel/time/timer.c:605
> internal_add_timer kernel/time/timer.c:634 [inline]
> __mod_timer+0xa76/0xf40 kernel/time/timer.c:1131
> mod_peer_timer+0x158/0x220
15 matches
Mail list logo