linux-kernel - Re: WARNING in __mutex_unlock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7f2ca5eb-a052-bbae-155a-5961e3b0ee61@redhat.com>
Date:   Tue, 8 May 2018 14:24:35 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
        syzbot <syzbot+35666cba7f0a337e2e79@...kaller.appspotmail.com>,
        syzkaller-bugs@...glegroups.com
Cc:     hpa@...or.com, kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        mingo@...hat.com, rkrcmar@...hat.com, tglx@...utronix.de,
        x86@...nel.org, Roman Kagan <rkagan@...tuozzo.com>,
        Cathy Avery <cavery@...hat.com>
Subject: Re: WARNING in __mutex_unlock_slowpath

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