lkml.org 
[lkml]   [2018]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: WARNING in __mutex_unlock_slowpath
From
Date
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->hv_lock);
> eventfd = idr_remove(&hv->conn_to_evt, conn_id); // <= Memory block containing hv->hv_lock was released by other thread and reallocated by other thread.
> mutex_unlock(&hv->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

\
 
 \ /
  Last update: 2018-05-08 14:25    [W:0.130 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site