Re: WARNING in __mutex_unlock_slowpath

2018-05-08 Thread Roman Kagan 
On Mon, May 07, 2018 at 07:19:04PM +0200, Paolo Bonzini wrote:
> On 29/04/2018 19:00, syzbot wrote:
> > syzbot hit the following crash on upstream commit
> > bf8f5de17442bba5f811e7e724980730e079ee11 (Sat Apr 28 17:05:04 2018 +)
> > MAINTAINERS: add myself as maintainer of AFFS
> > syzbot dashboard link:
> > https://syzkaller.appspot.com/bug?extid=35666cba7f0a337e2e79
> > 
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5686569910403072
> > syzkaller reproducer:
> > https://syzkaller.appspot.com/x/repro.syz?id=5767017265102848
> > Raw console output:
> > https://syzkaller.appspot.com/x/log.txt?id=6346308495343616
> > Kernel config:
> > https://syzkaller.appspot.com/x/.config?id=7043958930931867332
> > compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> > 
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+35666cba7f0a337e2...@syzkaller.appspotmail.com
> > It will help syzbot understand when the bug is fixed. See footer for
> > details.
> > If you forward the report, please keep this part and the footer.
> > 
> > [ cut here ]
> > DEBUG_LOCKS_WARN_ON(__owner_task(owner) != current)
> > WARNING: CPU: 0 PID: 4525 at kernel/locking/mutex.c:1032
> > __mutex_unlock_slowpath+0x62e/0x8a0 kernel/locking/mutex.c:1032
> > Kernel panic - not syncing: panic_on_warn set ...
> 
> This doesn't make much sense, unless it's a "generic" memory corruption,
> but at least the reproducer seems to be simple, just (in pseudocode)
> 
>   ioctl(kvm_vm_fd, KVM_HYPERV_EVENTFD,
> { fd = some_eventfd, conn_id = 0, flags = 0 })
>   ioctl(kvm_vm_fd, KVM_HYPERV_EVENTFD,
> { fd = -1, conn_id = 5, flags = KVM_HYPERV_EVENTFD_DEASSIGN })
> 
> Roman, Cathy, can you give it a quick look?  (Reproducing the reproducer
> link: https://syzkaller.appspot.com/x/repro.c?id=5686569910403072).

Something seems broken in the IDR machinery: IDR with a single id==0
entry reliably crashes when attempting to idr_remove a non-zero id.
Other combinations look fine: removing the existing id==0 entry;
removing a non-existing entry from an IDR with at least one id!=0 entry.

I still haven't pinpointed the root cause.
Cc-ing Matthew.

Roman.

Re: WARNING in __mutex_unlock_slowpath

2018-05-08 Thread Roman Kagan 
On Mon, May 07, 2018 at 07:19:04PM +0200, Paolo Bonzini wrote:
> On 29/04/2018 19:00, syzbot wrote:
> > syzbot hit the following crash on upstream commit
> > bf8f5de17442bba5f811e7e724980730e079ee11 (Sat Apr 28 17:05:04 2018 +)
> > MAINTAINERS: add myself as maintainer of AFFS
> > syzbot dashboard link:
> > https://syzkaller.appspot.com/bug?extid=35666cba7f0a337e2e79
> > 
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5686569910403072
> > syzkaller reproducer:
> > https://syzkaller.appspot.com/x/repro.syz?id=5767017265102848
> > Raw console output:
> > https://syzkaller.appspot.com/x/log.txt?id=6346308495343616
> > Kernel config:
> > https://syzkaller.appspot.com/x/.config?id=7043958930931867332
> > compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> > 
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+35666cba7f0a337e2...@syzkaller.appspotmail.com
> > It will help syzbot understand when the bug is fixed. See footer for
> > details.
> > If you forward the report, please keep this part and the footer.
> > 
> > [ cut here ]
> > DEBUG_LOCKS_WARN_ON(__owner_task(owner) != current)
> > WARNING: CPU: 0 PID: 4525 at kernel/locking/mutex.c:1032
> > __mutex_unlock_slowpath+0x62e/0x8a0 kernel/locking/mutex.c:1032
> > Kernel panic - not syncing: panic_on_warn set ...
> 
> This doesn't make much sense, unless it's a "generic" memory corruption,
> but at least the reproducer seems to be simple, just (in pseudocode)
> 
>   ioctl(kvm_vm_fd, KVM_HYPERV_EVENTFD,
> { fd = some_eventfd, conn_id = 0, flags = 0 })
>   ioctl(kvm_vm_fd, KVM_HYPERV_EVENTFD,
> { fd = -1, conn_id = 5, flags = KVM_HYPERV_EVENTFD_DEASSIGN })
> 
> Roman, Cathy, can you give it a quick look?  (Reproducing the reproducer
> link: https://syzkaller.appspot.com/x/repro.c?id=5686569910403072).

Something seems broken in the IDR machinery: IDR with a single id==0
entry reliably crashes when attempting to idr_remove a non-zero id.
Other combinations look fine: removing the existing id==0 entry;
removing a non-existing entry from an IDR with at least one id!=0 entry.

I still haven't pinpointed the root cause.
Cc-ing Matthew.

Roman.

Re: WARNING in __mutex_unlock_slowpath

2018-05-08 Thread Paolo Bonzini 
On 07/05/2018 23:49, Tetsuo Handa wrote:
> On 2018/05/08 2:19, Paolo Bonzini wrote:
>>> [ cut here ]
>>> DEBUG_LOCKS_WARN_ON(__owner_task(owner) != current)
>>> WARNING: CPU: 0 PID: 4525 at kernel/locking/mutex.c:1032
>>> __mutex_unlock_slowpath+0x62e/0x8a0 kernel/locking/mutex.c:1032
>>> Kernel panic - not syncing: panic_on_warn set ...
>>
>> This doesn't make much sense, unless it's a "generic" memory corruption,
>> but at least the reproducer seems to be simple, just (in pseudocode)
>>
>>   ioctl(kvm_vm_fd, KVM_HYPERV_EVENTFD,
>> { fd = some_eventfd, conn_id = 0, flags = 0 })
>>   ioctl(kvm_vm_fd, KVM_HYPERV_EVENTFD,
>> { fd = -1, conn_id = 5, flags = KVM_HYPERV_EVENTFD_DEASSIGN })
>>
> 
> This makes much sense if this is use-after-free memory access which was
> manifested differently due to reallocated after released.
> 
>   mutex_lock(>hv_lock);
>   eventfd = idr_remove(>conn_to_evt, conn_id); // <= Memory block 
> containing hv->hv_lock was released by other thread and reallocated by other 
> thread.
>   mutex_unlock(>hv_lock); // <= Hence, __owner_task(owner) != current at 
> this point.

Yes, but hv is part of the "struct kvm" and it should only be freed
after kvm_vm_fd (in the above pseudocode) is gone, so after both ioctls
are finished.  Unlike other syzkaller testcases this one doesn't really
require parallelism.

Paolo

Re: WARNING in __mutex_unlock_slowpath

2018-05-08 Thread Paolo Bonzini 
On 07/05/2018 23:49, Tetsuo Handa wrote:
> On 2018/05/08 2:19, Paolo Bonzini wrote:
>>> [ cut here ]
>>> DEBUG_LOCKS_WARN_ON(__owner_task(owner) != current)
>>> WARNING: CPU: 0 PID: 4525 at kernel/locking/mutex.c:1032
>>> __mutex_unlock_slowpath+0x62e/0x8a0 kernel/locking/mutex.c:1032
>>> Kernel panic - not syncing: panic_on_warn set ...
>>
>> This doesn't make much sense, unless it's a "generic" memory corruption,
>> but at least the reproducer seems to be simple, just (in pseudocode)
>>
>>   ioctl(kvm_vm_fd, KVM_HYPERV_EVENTFD,
>> { fd = some_eventfd, conn_id = 0, flags = 0 })
>>   ioctl(kvm_vm_fd, KVM_HYPERV_EVENTFD,
>> { fd = -1, conn_id = 5, flags = KVM_HYPERV_EVENTFD_DEASSIGN })
>>
> 
> This makes much sense if this is use-after-free memory access which was
> manifested differently due to reallocated after released.
> 
>   mutex_lock(>hv_lock);
>   eventfd = idr_remove(>conn_to_evt, conn_id); // <= Memory block 
> containing hv->hv_lock was released by other thread and reallocated by other 
> thread.
>   mutex_unlock(>hv_lock); // <= Hence, __owner_task(owner) != current at 
> this point.

Yes, but hv is part of the "struct kvm" and it should only be freed
after kvm_vm_fd (in the above pseudocode) is gone, so after both ioctls
are finished.  Unlike other syzkaller testcases this one doesn't really
require parallelism.

Paolo

Re: WARNING in __mutex_unlock_slowpath

2018-05-07 Thread Tetsuo Handa 
On 2018/05/08 2:19, Paolo Bonzini wrote:
>> [ cut here ]
>> DEBUG_LOCKS_WARN_ON(__owner_task(owner) != current)
>> WARNING: CPU: 0 PID: 4525 at kernel/locking/mutex.c:1032
>> __mutex_unlock_slowpath+0x62e/0x8a0 kernel/locking/mutex.c:1032
>> Kernel panic - not syncing: panic_on_warn set ...
> 
> This doesn't make much sense, unless it's a "generic" memory corruption,
> but at least the reproducer seems to be simple, just (in pseudocode)
> 
>   ioctl(kvm_vm_fd, KVM_HYPERV_EVENTFD,
> { fd = some_eventfd, conn_id = 0, flags = 0 })
>   ioctl(kvm_vm_fd, KVM_HYPERV_EVENTFD,
> { fd = -1, conn_id = 5, flags = KVM_HYPERV_EVENTFD_DEASSIGN })
> 

This makes much sense if this is use-after-free memory access which was
manifested differently due to reallocated after released.

  mutex_lock(>hv_lock);
  eventfd = idr_remove(>conn_to_evt, conn_id); // <= Memory block 
containing hv->hv_lock was released by other thread and reallocated by other 
thread.
  mutex_unlock(>hv_lock); // <= Hence, __owner_task(owner) != current at 
this point.

Re: WARNING in __mutex_unlock_slowpath

2018-05-07 Thread Tetsuo Handa 
On 2018/05/08 2:19, Paolo Bonzini wrote:
>> [ cut here ]
>> DEBUG_LOCKS_WARN_ON(__owner_task(owner) != current)
>> WARNING: CPU: 0 PID: 4525 at kernel/locking/mutex.c:1032
>> __mutex_unlock_slowpath+0x62e/0x8a0 kernel/locking/mutex.c:1032
>> Kernel panic - not syncing: panic_on_warn set ...
> 
> This doesn't make much sense, unless it's a "generic" memory corruption,
> but at least the reproducer seems to be simple, just (in pseudocode)
> 
>   ioctl(kvm_vm_fd, KVM_HYPERV_EVENTFD,
> { fd = some_eventfd, conn_id = 0, flags = 0 })
>   ioctl(kvm_vm_fd, KVM_HYPERV_EVENTFD,
> { fd = -1, conn_id = 5, flags = KVM_HYPERV_EVENTFD_DEASSIGN })
> 

This makes much sense if this is use-after-free memory access which was
manifested differently due to reallocated after released.

  mutex_lock(>hv_lock);
  eventfd = idr_remove(>conn_to_evt, conn_id); // <= Memory block 
containing hv->hv_lock was released by other thread and reallocated by other 
thread.
  mutex_unlock(>hv_lock); // <= Hence, __owner_task(owner) != current at 
this point.

Re: WARNING in __mutex_unlock_slowpath

2018-05-07 Thread Paolo Bonzini 
On 07/05/2018 19:31, Dmitry Vyukov wrote:
> May be related to:
> 
> https://syzkaller.appspot.com/bug?id=aec313f3f7ebc2ee0abb1104a3631ab8fd1e90f2
> 

Yeah, most likely.

Paolo

Re: WARNING in __mutex_unlock_slowpath

2018-05-07 Thread Paolo Bonzini 
On 07/05/2018 19:31, Dmitry Vyukov wrote:
> May be related to:
> 
> https://syzkaller.appspot.com/bug?id=aec313f3f7ebc2ee0abb1104a3631ab8fd1e90f2
> 

Yeah, most likely.

Paolo

Re: WARNING in __mutex_unlock_slowpath

2018-05-07 Thread Dmitry Vyukov 
On Mon, May 7, 2018 at 7:19 PM, Paolo Bonzini  wrote:
> On 29/04/2018 19:00, syzbot wrote:
>> Hello,
>>
>> syzbot hit the following crash on upstream commit
>> bf8f5de17442bba5f811e7e724980730e079ee11 (Sat Apr 28 17:05:04 2018 +)
>> MAINTAINERS: add myself as maintainer of AFFS
>> syzbot dashboard link:
>> https://syzkaller.appspot.com/bug?extid=35666cba7f0a337e2e79
>>
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5686569910403072
>> syzkaller reproducer:
>> https://syzkaller.appspot.com/x/repro.syz?id=5767017265102848
>> Raw console output:
>> https://syzkaller.appspot.com/x/log.txt?id=6346308495343616
>> Kernel config:
>> https://syzkaller.appspot.com/x/.config?id=7043958930931867332
>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+35666cba7f0a337e2...@syzkaller.appspotmail.com
>> It will help syzbot understand when the bug is fixed. See footer for
>> details.
>> If you forward the report, please keep this part and the footer.
>>
>> [ cut here ]
>> DEBUG_LOCKS_WARN_ON(__owner_task(owner) != current)
>> WARNING: CPU: 0 PID: 4525 at kernel/locking/mutex.c:1032
>> __mutex_unlock_slowpath+0x62e/0x8a0 kernel/locking/mutex.c:1032
>> Kernel panic - not syncing: panic_on_warn set ...
>
> This doesn't make much sense, unless it's a "generic" memory corruption,
> but at least the reproducer seems to be simple, just (in pseudocode)
>
>   ioctl(kvm_vm_fd, KVM_HYPERV_EVENTFD,
> { fd = some_eventfd, conn_id = 0, flags = 0 })
>   ioctl(kvm_vm_fd, KVM_HYPERV_EVENTFD,
> { fd = -1, conn_id = 5, flags = KVM_HYPERV_EVENTFD_DEASSIGN })
>
> Roman, Cathy, can you give it a quick look?  (Reproducing the reproducer
> link: https://syzkaller.appspot.com/x/repro.c?id=5686569910403072).
>
> Paolo

May be related to:

https://syzkaller.appspot.com/bug?id=aec313f3f7ebc2ee0abb1104a3631ab8fd1e90f2

>> CPU: 0 PID: 4525 Comm: syz-executor809 Not tainted 4.17.0-rc2+ #22
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>>  __dump_stack lib/dump_stack.c:77 [inline]
>>  dump_stack+0x1b9/0x294 lib/dump_stack.c:113
>>  panic+0x22f/0x4de kernel/panic.c:184
>>  __warn.cold.8+0x163/0x1b3 kernel/panic.c:536
>>  report_bug+0x252/0x2d0 lib/bug.c:186
>>  fixup_bug arch/x86/kernel/traps.c:178 [inline]
>>  do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296
>>  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
>>  invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
>> RIP: 0010:__mutex_unlock_slowpath+0x62e/0x8a0 kernel/locking/mutex.c:1032
>> RSP: 0018:8801cf31f138 EFLAGS: 00010286
>> RAX: 0033 RBX: 110039e63e30 RCX: 8160b82d
>> RDX:  RSI: 816104e1 RDI: 0001
>> RBP: 8801cf31f2a8 R08: 8801d9042180 R09: fbfff11b0974
>> R10: fbfff11b0974 R11: 88d84ba3 R12: 8a713a20
>> R13: dc00 R14:  R15: 8801989d6b08
>>  mutex_unlock+0xd/0x10 kernel/locking/mutex.c:614
>>  kvm_hv_eventfd_deassign arch/x86/kvm/hyperv.c:1434 [inline]
>>  kvm_vm_ioctl_hv_eventfd+0x1ea/0x24b arch/x86/kvm/hyperv.c:1451
>>  kvm_arch_vm_ioctl+0x155e/0x2690 arch/x86/kvm/x86.c:4563
>>  kvm_vm_ioctl+0x246/0x1d90 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3100
>>  vfs_ioctl fs/ioctl.c:46 [inline]
>>  file_ioctl fs/ioctl.c:500 [inline]
>>  do_vfs_ioctl+0x1cf/0x16a0 fs/ioctl.c:684
>>  ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701
>>  __do_sys_ioctl fs/ioctl.c:708 [inline]
>>  __se_sys_ioctl fs/ioctl.c:706 [inline]
>>  __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:706
>>  do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
>>  entry_SYSCALL_64_after_hwframe+0x49/0xbe
>> RIP: 0033:0x4401f9
>> RSP: 002b:7ffcd5727a48 EFLAGS: 0217 ORIG_RAX: 0010
>> RAX: ffda RBX: 6d766b2f7665642f RCX: 004401f9
>> RDX: 2140 RSI: 4018aebd RDI: 00ee
>> RBP: 006ca018 R08: 004002c8 R09: 004002c8
>> R10: 004002c8 R11: 0217 R12: 00401720
>> R13: 004017b0 R14:  R15: 
>> Dumping ftrace buffer:
>>(ftrace buffer empty)
>> Kernel Offset: disabled
>> Rebooting in 86400 seconds..
>>
>>
>> ---
>> This bug is generated by a dumb bot. It may contain errors.
>> See https://goo.gl/tpsmEJ for details.
>> Direct all questions to syzkal...@googlegroups.com.
>>
>> syzbot will keep track of this bug report.
>> If you forgot to add the Reported-by tag, once the fix for this bug is
>> merged
>> into any tree, please reply to this email with:
>> #syz fix: exact-commit-title
>> If you want to test a patch for this bug, please reply with:
>> #syz test: git://repo/address.git branch
>> and provide the patch inline or as an attachment.
>> To mark this as a duplicate of another syzbot report, please reply with:
>> #syz dup:

Re: WARNING in __mutex_unlock_slowpath

2018-05-07 Thread Dmitry Vyukov 
On Mon, May 7, 2018 at 7:19 PM, Paolo Bonzini  wrote:
> On 29/04/2018 19:00, syzbot wrote:
>> Hello,
>>
>> syzbot hit the following crash on upstream commit
>> bf8f5de17442bba5f811e7e724980730e079ee11 (Sat Apr 28 17:05:04 2018 +)
>> MAINTAINERS: add myself as maintainer of AFFS
>> syzbot dashboard link:
>> https://syzkaller.appspot.com/bug?extid=35666cba7f0a337e2e79
>>
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5686569910403072
>> syzkaller reproducer:
>> https://syzkaller.appspot.com/x/repro.syz?id=5767017265102848
>> Raw console output:
>> https://syzkaller.appspot.com/x/log.txt?id=6346308495343616
>> Kernel config:
>> https://syzkaller.appspot.com/x/.config?id=7043958930931867332
>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+35666cba7f0a337e2...@syzkaller.appspotmail.com
>> It will help syzbot understand when the bug is fixed. See footer for
>> details.
>> If you forward the report, please keep this part and the footer.
>>
>> [ cut here ]
>> DEBUG_LOCKS_WARN_ON(__owner_task(owner) != current)
>> WARNING: CPU: 0 PID: 4525 at kernel/locking/mutex.c:1032
>> __mutex_unlock_slowpath+0x62e/0x8a0 kernel/locking/mutex.c:1032
>> Kernel panic - not syncing: panic_on_warn set ...
>
> This doesn't make much sense, unless it's a "generic" memory corruption,
> but at least the reproducer seems to be simple, just (in pseudocode)
>
>   ioctl(kvm_vm_fd, KVM_HYPERV_EVENTFD,
> { fd = some_eventfd, conn_id = 0, flags = 0 })
>   ioctl(kvm_vm_fd, KVM_HYPERV_EVENTFD,
> { fd = -1, conn_id = 5, flags = KVM_HYPERV_EVENTFD_DEASSIGN })
>
> Roman, Cathy, can you give it a quick look?  (Reproducing the reproducer
> link: https://syzkaller.appspot.com/x/repro.c?id=5686569910403072).
>
> Paolo

May be related to:

https://syzkaller.appspot.com/bug?id=aec313f3f7ebc2ee0abb1104a3631ab8fd1e90f2

>> CPU: 0 PID: 4525 Comm: syz-executor809 Not tainted 4.17.0-rc2+ #22
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>>  __dump_stack lib/dump_stack.c:77 [inline]
>>  dump_stack+0x1b9/0x294 lib/dump_stack.c:113
>>  panic+0x22f/0x4de kernel/panic.c:184
>>  __warn.cold.8+0x163/0x1b3 kernel/panic.c:536
>>  report_bug+0x252/0x2d0 lib/bug.c:186
>>  fixup_bug arch/x86/kernel/traps.c:178 [inline]
>>  do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296
>>  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
>>  invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
>> RIP: 0010:__mutex_unlock_slowpath+0x62e/0x8a0 kernel/locking/mutex.c:1032
>> RSP: 0018:8801cf31f138 EFLAGS: 00010286
>> RAX: 0033 RBX: 110039e63e30 RCX: 8160b82d
>> RDX:  RSI: 816104e1 RDI: 0001
>> RBP: 8801cf31f2a8 R08: 8801d9042180 R09: fbfff11b0974
>> R10: fbfff11b0974 R11: 88d84ba3 R12: 8a713a20
>> R13: dc00 R14:  R15: 8801989d6b08
>>  mutex_unlock+0xd/0x10 kernel/locking/mutex.c:614
>>  kvm_hv_eventfd_deassign arch/x86/kvm/hyperv.c:1434 [inline]
>>  kvm_vm_ioctl_hv_eventfd+0x1ea/0x24b arch/x86/kvm/hyperv.c:1451
>>  kvm_arch_vm_ioctl+0x155e/0x2690 arch/x86/kvm/x86.c:4563
>>  kvm_vm_ioctl+0x246/0x1d90 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3100
>>  vfs_ioctl fs/ioctl.c:46 [inline]
>>  file_ioctl fs/ioctl.c:500 [inline]
>>  do_vfs_ioctl+0x1cf/0x16a0 fs/ioctl.c:684
>>  ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701
>>  __do_sys_ioctl fs/ioctl.c:708 [inline]
>>  __se_sys_ioctl fs/ioctl.c:706 [inline]
>>  __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:706
>>  do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
>>  entry_SYSCALL_64_after_hwframe+0x49/0xbe
>> RIP: 0033:0x4401f9
>> RSP: 002b:7ffcd5727a48 EFLAGS: 0217 ORIG_RAX: 0010
>> RAX: ffda RBX: 6d766b2f7665642f RCX: 004401f9
>> RDX: 2140 RSI: 4018aebd RDI: 00ee
>> RBP: 006ca018 R08: 004002c8 R09: 004002c8
>> R10: 004002c8 R11: 0217 R12: 00401720
>> R13: 004017b0 R14:  R15: 
>> Dumping ftrace buffer:
>>(ftrace buffer empty)
>> Kernel Offset: disabled
>> Rebooting in 86400 seconds..
>>
>>
>> ---
>> This bug is generated by a dumb bot. It may contain errors.
>> See https://goo.gl/tpsmEJ for details.
>> Direct all questions to syzkal...@googlegroups.com.
>>
>> syzbot will keep track of this bug report.
>> If you forgot to add the Reported-by tag, once the fix for this bug is
>> merged
>> into any tree, please reply to this email with:
>> #syz fix: exact-commit-title
>> If you want to test a patch for this bug, please reply with:
>> #syz test: git://repo/address.git branch
>> and provide the patch inline or as an attachment.
>> To mark this as a duplicate of another syzbot report, please reply with:
>> #syz dup:

Re: WARNING in __mutex_unlock_slowpath

2018-05-07 Thread Paolo Bonzini 
On 29/04/2018 19:00, syzbot wrote:
> Hello,
> 
> syzbot hit the following crash on upstream commit
> bf8f5de17442bba5f811e7e724980730e079ee11 (Sat Apr 28 17:05:04 2018 +)
> MAINTAINERS: add myself as maintainer of AFFS
> syzbot dashboard link:
> https://syzkaller.appspot.com/bug?extid=35666cba7f0a337e2e79
> 
> C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5686569910403072
> syzkaller reproducer:
> https://syzkaller.appspot.com/x/repro.syz?id=5767017265102848
> Raw console output:
> https://syzkaller.appspot.com/x/log.txt?id=6346308495343616
> Kernel config:
> https://syzkaller.appspot.com/x/.config?id=7043958930931867332
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+35666cba7f0a337e2...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> [ cut here ]
> DEBUG_LOCKS_WARN_ON(__owner_task(owner) != current)
> WARNING: CPU: 0 PID: 4525 at kernel/locking/mutex.c:1032
> __mutex_unlock_slowpath+0x62e/0x8a0 kernel/locking/mutex.c:1032
> Kernel panic - not syncing: panic_on_warn set ...

This doesn't make much sense, unless it's a "generic" memory corruption,
but at least the reproducer seems to be simple, just (in pseudocode)

  ioctl(kvm_vm_fd, KVM_HYPERV_EVENTFD,
{ fd = some_eventfd, conn_id = 0, flags = 0 })
  ioctl(kvm_vm_fd, KVM_HYPERV_EVENTFD,
{ fd = -1, conn_id = 5, flags = KVM_HYPERV_EVENTFD_DEASSIGN })

Roman, Cathy, can you give it a quick look?  (Reproducing the reproducer
link: https://syzkaller.appspot.com/x/repro.c?id=5686569910403072).

Paolo

> CPU: 0 PID: 4525 Comm: syz-executor809 Not tainted 4.17.0-rc2+ #22
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:77 [inline]
>  dump_stack+0x1b9/0x294 lib/dump_stack.c:113
>  panic+0x22f/0x4de kernel/panic.c:184
>  __warn.cold.8+0x163/0x1b3 kernel/panic.c:536
>  report_bug+0x252/0x2d0 lib/bug.c:186
>  fixup_bug arch/x86/kernel/traps.c:178 [inline]
>  do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296
>  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
>  invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
> RIP: 0010:__mutex_unlock_slowpath+0x62e/0x8a0 kernel/locking/mutex.c:1032
> RSP: 0018:8801cf31f138 EFLAGS: 00010286
> RAX: 0033 RBX: 110039e63e30 RCX: 8160b82d
> RDX:  RSI: 816104e1 RDI: 0001
> RBP: 8801cf31f2a8 R08: 8801d9042180 R09: fbfff11b0974
> R10: fbfff11b0974 R11: 88d84ba3 R12: 8a713a20
> R13: dc00 R14:  R15: 8801989d6b08
>  mutex_unlock+0xd/0x10 kernel/locking/mutex.c:614
>  kvm_hv_eventfd_deassign arch/x86/kvm/hyperv.c:1434 [inline]
>  kvm_vm_ioctl_hv_eventfd+0x1ea/0x24b arch/x86/kvm/hyperv.c:1451
>  kvm_arch_vm_ioctl+0x155e/0x2690 arch/x86/kvm/x86.c:4563
>  kvm_vm_ioctl+0x246/0x1d90 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3100
>  vfs_ioctl fs/ioctl.c:46 [inline]
>  file_ioctl fs/ioctl.c:500 [inline]
>  do_vfs_ioctl+0x1cf/0x16a0 fs/ioctl.c:684
>  ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701
>  __do_sys_ioctl fs/ioctl.c:708 [inline]
>  __se_sys_ioctl fs/ioctl.c:706 [inline]
>  __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:706
>  do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
>  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x4401f9
> RSP: 002b:7ffcd5727a48 EFLAGS: 0217 ORIG_RAX: 0010
> RAX: ffda RBX: 6d766b2f7665642f RCX: 004401f9
> RDX: 2140 RSI: 4018aebd RDI: 00ee
> RBP: 006ca018 R08: 004002c8 R09: 004002c8
> R10: 004002c8 R11: 0217 R12: 00401720
> R13: 004017b0 R14:  R15: 
> Dumping ftrace buffer:
>    (ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
> 
> 
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkal...@googlegroups.com.
> 
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> If you want to test a patch for this bug, please reply with:
> #syz test: git://repo/address.git branch
> and provide the patch inline or as an attachment.
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug
> report.
> Note: all commands must start from beginning of the line in the email body.

Re: WARNING in __mutex_unlock_slowpath

2018-05-07 Thread Paolo Bonzini 
On 29/04/2018 19:00, syzbot wrote:
> Hello,
> 
> syzbot hit the following crash on upstream commit
> bf8f5de17442bba5f811e7e724980730e079ee11 (Sat Apr 28 17:05:04 2018 +)
> MAINTAINERS: add myself as maintainer of AFFS
> syzbot dashboard link:
> https://syzkaller.appspot.com/bug?extid=35666cba7f0a337e2e79
> 
> C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5686569910403072
> syzkaller reproducer:
> https://syzkaller.appspot.com/x/repro.syz?id=5767017265102848
> Raw console output:
> https://syzkaller.appspot.com/x/log.txt?id=6346308495343616
> Kernel config:
> https://syzkaller.appspot.com/x/.config?id=7043958930931867332
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+35666cba7f0a337e2...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> [ cut here ]
> DEBUG_LOCKS_WARN_ON(__owner_task(owner) != current)
> WARNING: CPU: 0 PID: 4525 at kernel/locking/mutex.c:1032
> __mutex_unlock_slowpath+0x62e/0x8a0 kernel/locking/mutex.c:1032
> Kernel panic - not syncing: panic_on_warn set ...

This doesn't make much sense, unless it's a "generic" memory corruption,
but at least the reproducer seems to be simple, just (in pseudocode)

  ioctl(kvm_vm_fd, KVM_HYPERV_EVENTFD,
{ fd = some_eventfd, conn_id = 0, flags = 0 })
  ioctl(kvm_vm_fd, KVM_HYPERV_EVENTFD,
{ fd = -1, conn_id = 5, flags = KVM_HYPERV_EVENTFD_DEASSIGN })

Roman, Cathy, can you give it a quick look?  (Reproducing the reproducer
link: https://syzkaller.appspot.com/x/repro.c?id=5686569910403072).

Paolo

> CPU: 0 PID: 4525 Comm: syz-executor809 Not tainted 4.17.0-rc2+ #22
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:77 [inline]
>  dump_stack+0x1b9/0x294 lib/dump_stack.c:113
>  panic+0x22f/0x4de kernel/panic.c:184
>  __warn.cold.8+0x163/0x1b3 kernel/panic.c:536
>  report_bug+0x252/0x2d0 lib/bug.c:186
>  fixup_bug arch/x86/kernel/traps.c:178 [inline]
>  do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296
>  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
>  invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
> RIP: 0010:__mutex_unlock_slowpath+0x62e/0x8a0 kernel/locking/mutex.c:1032
> RSP: 0018:8801cf31f138 EFLAGS: 00010286
> RAX: 0033 RBX: 110039e63e30 RCX: 8160b82d
> RDX:  RSI: 816104e1 RDI: 0001
> RBP: 8801cf31f2a8 R08: 8801d9042180 R09: fbfff11b0974
> R10: fbfff11b0974 R11: 88d84ba3 R12: 8a713a20
> R13: dc00 R14:  R15: 8801989d6b08
>  mutex_unlock+0xd/0x10 kernel/locking/mutex.c:614
>  kvm_hv_eventfd_deassign arch/x86/kvm/hyperv.c:1434 [inline]
>  kvm_vm_ioctl_hv_eventfd+0x1ea/0x24b arch/x86/kvm/hyperv.c:1451
>  kvm_arch_vm_ioctl+0x155e/0x2690 arch/x86/kvm/x86.c:4563
>  kvm_vm_ioctl+0x246/0x1d90 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3100
>  vfs_ioctl fs/ioctl.c:46 [inline]
>  file_ioctl fs/ioctl.c:500 [inline]
>  do_vfs_ioctl+0x1cf/0x16a0 fs/ioctl.c:684
>  ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701
>  __do_sys_ioctl fs/ioctl.c:708 [inline]
>  __se_sys_ioctl fs/ioctl.c:706 [inline]
>  __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:706
>  do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
>  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x4401f9
> RSP: 002b:7ffcd5727a48 EFLAGS: 0217 ORIG_RAX: 0010
> RAX: ffda RBX: 6d766b2f7665642f RCX: 004401f9
> RDX: 2140 RSI: 4018aebd RDI: 00ee
> RBP: 006ca018 R08: 004002c8 R09: 004002c8
> R10: 004002c8 R11: 0217 R12: 00401720
> R13: 004017b0 R14:  R15: 
> Dumping ftrace buffer:
>    (ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
> 
> 
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkal...@googlegroups.com.
> 
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> If you want to test a patch for this bug, please reply with:
> #syz test: git://repo/address.git branch
> and provide the patch inline or as an attachment.
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug
> report.
> Note: all commands must start from beginning of the line in the email body.