Hello,
syzbot found the following issue on:
HEAD commit: 0f4498ce Merge tag 'for-5.12/dm-fixes-2' of git://git.kern..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=124adbf6d00000
kernel config: https://syzkaller.appspot.com/x/.config?x=daeff30c2474a60f
dashboard link: https://syzkaller.appspot.com/bug?extid=eb4674092e6cc8d9e0bd
userspace arch: i386
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: [email protected]
general protection fault, probably for non-canonical address 0xdffffc0000000004: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]
CPU: 1 PID: 5016 Comm: systemd-udevd Not tainted 5.12.0-rc4-syzkaller #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
RIP: 0010:__lock_acquire+0xcfe/0x54c0 kernel/locking/lockdep.c:4770
Code: 09 0e 41 bf 01 00 00 00 0f 86 8c 00 00 00 89 05 48 69 09 0e e9 81 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 ea 03 <80> 3c 02 00 0f 85 5b 31 00 00 49 81 3e c0 13 38 8f 0f 84 d0 f3 ff
RSP: 0000:ffffc90000ce77d8 EFLAGS: 00010002
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000004 RSI: 1ffff9200019cf0c RDI: 0000000000000020
RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000001 R11: 0000000000000006 R12: ffff88801295b880
R13: 0000000000000000 R14: 0000000000000020 R15: 0000000000000000
FS: 00007fcd745f98c0(0000) GS:ffff88802cb00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffe279f7d87 CR3: 000000001c7d4000 CR4: 0000000000150ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
lock_acquire kernel/locking/lockdep.c:5510 [inline]
lock_acquire+0x1ab/0x740 kernel/locking/lockdep.c:5475
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x39/0x50 kernel/locking/spinlock.c:159
gadget_setup+0x4e/0x510 drivers/usb/gadget/legacy/raw_gadget.c:327
dummy_timer+0x1615/0x32a0 drivers/usb/gadget/udc/dummy_hcd.c:1903
call_timer_fn+0x1a5/0x6b0 kernel/time/timer.c:1431
expire_timers kernel/time/timer.c:1476 [inline]
__run_timers.part.0+0x67c/0xa50 kernel/time/timer.c:1745
__run_timers kernel/time/timer.c:1726 [inline]
run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1758
__do_softirq+0x29b/0x9f6 kernel/softirq.c:345
invoke_softirq kernel/softirq.c:221 [inline]
__irq_exit_rcu kernel/softirq.c:422 [inline]
irq_exit_rcu+0x134/0x200 kernel/softirq.c:434
sysvec_apic_timer_interrupt+0x45/0xc0 arch/x86/kernel/apic/apic.c:1100
asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:632
RIP: 0033:0x560cfc4a02ed
Code: 4c 39 c1 48 89 42 18 4c 89 52 08 4c 89 5a 10 48 89 1a 0f 87 7b ff ff ff 48 89 f8 48 f7 d0 48 01 c8 48 83 e0 f8 48 8d 7c 07 08 <48> 8d 0d 34 d9 02 00 48 63 04 b1 48 01 c8 ff e0 0f 1f 00 48 8d 0d
RSP: 002b:00007ffe279f9dd0 EFLAGS: 00000246
RAX: 0000000000000000 RBX: 0000560cfcd88e40 RCX: 0000560cfcd72af0
RDX: 00007ffe279f9de0 RSI: 0000000000000007 RDI: 0000560cfcd72af0
RBP: 00007ffe279f9e70 R08: 0000000000000000 R09: 0000000000000020
R10: 0000560cfcd72af7 R11: 0000560cfcd73530 R12: 0000560cfcd72af0
R13: 0000000000000000 R14: 0000560cfcd72b10 R15: 0000000000000001
Modules linked in:
---[ end trace ab0f6632fdd289cf ]---
RIP: 0010:__lock_acquire+0xcfe/0x54c0 kernel/locking/lockdep.c:4770
Code: 09 0e 41 bf 01 00 00 00 0f 86 8c 00 00 00 89 05 48 69 09 0e e9 81 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 ea 03 <80> 3c 02 00 0f 85 5b 31 00 00 49 81 3e c0 13 38 8f 0f 84 d0 f3 ff
RSP: 0000:ffffc90000ce77d8 EFLAGS: 00010002
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000004 RSI: 1ffff9200019cf0c RDI: 0000000000000020
RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000001 R11: 0000000000000006 R12: ffff88801295b880
R13: 0000000000000000 R14: 0000000000000020 R15: 0000000000000000
FS: 00007fcd745f98c0(0000) GS:ffff88802cb00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffe279f7d87 CR3: 000000001c7d4000 CR4: 0000000000150ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at [email protected].
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
On Tue, Apr 13, 2021 at 06:47:47PM +0200, Dmitry Vyukov wrote:
> On Tue, Apr 13, 2021 at 6:13 PM Alan Stern <[email protected]> wrote:
> > Hopefully this patch will make the race a lot more likely to occur. Is
> > there any way to tell syzkaller to test it, despite the fact that
> > syzkaller doesn't think it has a reproducer for this issue?
>
> If there is no reproducer the only way syzbot can test it is if it's
> in linux-next under CONFIG_DEBUG_AID_FOR_SYZBOT:
> http://bit.do/syzbot#no-custom-patches
There _is_ a theoretical reproducer: the test that provoked syzkaller's
original bug report. But syzkaller doesn't realize that it is (or may
be) a reproducer.
It ought to be possible to ask syzkaller to run a particular test that
it has done before, with a patch applied -- and without having to add
anything to linux-next.
Alan Stern
On Tue, Apr 13, 2021 at 6:57 PM Alan Stern <[email protected]> wrote:
>
> On Tue, Apr 13, 2021 at 06:47:47PM +0200, Dmitry Vyukov wrote:
> > On Tue, Apr 13, 2021 at 6:13 PM Alan Stern <[email protected]> wrote:
> > > Hopefully this patch will make the race a lot more likely to occur. Is
> > > there any way to tell syzkaller to test it, despite the fact that
> > > syzkaller doesn't think it has a reproducer for this issue?
> >
> > If there is no reproducer the only way syzbot can test it is if it's
> > in linux-next under CONFIG_DEBUG_AID_FOR_SYZBOT:
> > http://bit.do/syzbot#no-custom-patches
>
> There _is_ a theoretical reproducer: the test that provoked syzkaller's
> original bug report. But syzkaller doesn't realize that it is (or may
> be) a reproducer.
>
> It ought to be possible to ask syzkaller to run a particular test that
> it has done before, with a patch applied -- and without having to add
> anything to linux-next.
Yes, this is possible:
http://bit.do/syzbot#syzkaller-reproducers
The log of tests executed before the crash is available under the
"console output" link:
console output: https://syzkaller.appspot.com/x/log.txt?x=124adbf6d00000
And this log can be replayed using syz-execprog utility.
On Tue, Apr 13, 2021 at 07:11:11PM +0200, Dmitry Vyukov wrote:
> On Tue, Apr 13, 2021 at 6:57 PM Alan Stern <[email protected]> wrote:
> >
> > On Tue, Apr 13, 2021 at 06:47:47PM +0200, Dmitry Vyukov wrote:
> > > On Tue, Apr 13, 2021 at 6:13 PM Alan Stern <[email protected]> wrote:
> > > > Hopefully this patch will make the race a lot more likely to occur. Is
> > > > there any way to tell syzkaller to test it, despite the fact that
> > > > syzkaller doesn't think it has a reproducer for this issue?
> > >
> > > If there is no reproducer the only way syzbot can test it is if it's
> > > in linux-next under CONFIG_DEBUG_AID_FOR_SYZBOT:
> > > http://bit.do/syzbot#no-custom-patches
> >
> > There _is_ a theoretical reproducer: the test that provoked syzkaller's
> > original bug report. But syzkaller doesn't realize that it is (or may
> > be) a reproducer.
> >
> > It ought to be possible to ask syzkaller to run a particular test that
> > it has done before, with a patch applied -- and without having to add
> > anything to linux-next.
>
> Yes, this is possible:
> http://bit.do/syzbot#syzkaller-reproducers
That's not really what I had in mind. I don't want to spend the time
and effort installing syskaller on my own system; I want to tell syzbot
to run a particular syzkaller program (the one that originally led to
this bug report) on a patched kernel.
The syzbot instructions say that it can test bugs with reproducers. The
problem here is that there doesn't seem to be any way to tell it to use
a particular syzkaller program as a reproducer.
Alan Stern
> The log of tests executed before the crash is available under the
> "console output" link:
> console output: https://syzkaller.appspot.com/x/log.txt?x=124adbf6d00000
> And this log can be replayed using syz-execprog utility.
On Thu, Apr 15, 2021 at 10:59 PM Alan Stern <[email protected]> wrote:
>
> On Tue, Apr 13, 2021 at 07:11:11PM +0200, Dmitry Vyukov wrote:
> > On Tue, Apr 13, 2021 at 6:57 PM Alan Stern <[email protected]> wrote:
> > >
> > > On Tue, Apr 13, 2021 at 06:47:47PM +0200, Dmitry Vyukov wrote:
> > > > On Tue, Apr 13, 2021 at 6:13 PM Alan Stern <[email protected]> wrote:
> > > > > Hopefully this patch will make the race a lot more likely to occur. Is
> > > > > there any way to tell syzkaller to test it, despite the fact that
> > > > > syzkaller doesn't think it has a reproducer for this issue?
> > > >
> > > > If there is no reproducer the only way syzbot can test it is if it's
> > > > in linux-next under CONFIG_DEBUG_AID_FOR_SYZBOT:
> > > > http://bit.do/syzbot#no-custom-patches
> > >
> > > There _is_ a theoretical reproducer: the test that provoked syzkaller's
> > > original bug report. But syzkaller doesn't realize that it is (or may
> > > be) a reproducer.
> > >
> > > It ought to be possible to ask syzkaller to run a particular test that
> > > it has done before, with a patch applied -- and without having to add
> > > anything to linux-next.
> >
> > Yes, this is possible:
> > http://bit.do/syzbot#syzkaller-reproducers
>
> That's not really what I had in mind. I don't want to spend the time
> and effort installing syskaller on my own system; I want to tell syzbot
> to run a particular syzkaller program (the one that originally led to
> this bug report) on a patched kernel.
>
> The syzbot instructions say that it can test bugs with reproducers. The
> problem here is that there doesn't seem to be any way to tell it to use
> a particular syzkaller program as a reproducer.
Hi Alan,
This makes sense and I've found an existing feature request:
https://github.com/google/syzkaller/issues/1611
I've added a reference to this thread there.
On Fri, Apr 16, 2021 at 09:21:12AM +0200, Dmitry Vyukov wrote:
> On Thu, Apr 15, 2021 at 10:59 PM Alan Stern <[email protected]> wrote:
> >
> > On Tue, Apr 13, 2021 at 07:11:11PM +0200, Dmitry Vyukov wrote:
> > > Yes, this is possible:
> > > http://bit.do/syzbot#syzkaller-reproducers
> >
> > That's not really what I had in mind. I don't want to spend the time
> > and effort installing syskaller on my own system; I want to tell syzbot
> > to run a particular syzkaller program (the one that originally led to
> > this bug report) on a patched kernel.
> >
> > The syzbot instructions say that it can test bugs with reproducers. The
> > problem here is that there doesn't seem to be any way to tell it to use
> > a particular syzkaller program as a reproducer.
>
> Hi Alan,
>
> This makes sense and I've found an existing feature request:
> https://github.com/google/syzkaller/issues/1611
> I've added a reference to this thread there.
Great! Thank you.
Alan Stern