linux-kernel - Re: kernel BUG at arch/x86/kvm/x86.c:LINE! (2)

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CACT4Y+Y267HH=JXLJzwLOD4Q7A=ah39UwbeEA9wa_dR8NWNrnA@mail.gmail.com>
Date:   Thu, 11 Oct 2018 20:05:02 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     Du Changbin <duchangbin3@...wei.com>,
        syzbot <syzbot+f9b42efadea9f5453100@...kaller.appspotmail.com>,
        Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>, KVM list <kvm@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>,
        Radim Krčmář <rkrcmar@...hat.com>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "the arch/x86 maintainers" <x86@...nel.org>, changbin.du@...wei.com
Subject: Re: kernel BUG at arch/x86/kvm/x86.c:LINE! (2)

On Thu, Oct 11, 2018 at 4:32 PM, Paolo Bonzini <pbonzini@...hat.com> wrote:
> On 11/10/2018 04:57, Du Changbin wrote:
>> I think the issue is that using vmx instructions after vmx off. The
>> scenario is:
>> 1. kernel is rebooting and vmx is turned off by notification handler
>> kvm_reboot(),
>>    and 'kvm_rebooting' is set.
>> 2. But there is a pending KVM_CREATE_VCPU ioctl which will invoke
>> vmcs_clear()->
>>    ____kvm_handle_fault_on_reboot()->kvm_spurious_fault()->BUG().
>>
>> Need to improve the handler for such case so won't hang kernel.
>
> Why would the kernel be rebooting, given the reproducer (listed below my
> signature, or at https://syzkaller.appspot.com/x/repro.c?x=131e37c9400000)?
>
> I think this is a duplicate of
>
>    WARNING: refcount bug in kvm_vm_ioctl
>    BUG: unable to handle kernel paging request in
> refcount_inc_not_zero_checked
>
> In all cases the refcounts seem to be broken, and kvm_destroy_kvm is
> called prematurely (which in this case results in hardware_disable_all
> being called, so that the vmclear fails).
>
> Dmitry, have such bugs been reported for subsystems other than KVM?

We have _all_ types of bugs reported in _all_ subsystems. So you need
to be more precise :)

You can see all currently open bugs here:
https://syzkaller.appspot.com/#upstream

And here you can search over reports:
https://groups.google.com/forum/#!forum/syzkaller-bugs

E.g.:
https://groups.google.com/forum/#!searchin/syzkaller-bugs/refcount_inc_not_zero_checked

We had this recently, which is task_struct refcount bug:
https://syzkaller.appspot.com/bug?id=e1854417677586ce3d00f498f19816cb4fd15676
but this seems to be related to rdma. And repro for this bug only
deals with kvm. So my guess would be that this is a different bug in
kvm.
If you can reproduce it, then perhaps logging all refcount operation
on the thing will help to find whoever releases a ref it does not own.


> Paolo
>
> #syz dup: WARNING: refcount bug in kvm_vm_ioctl
>
>> # See https://goo.gl/kgGztJ for information about syzkaller reproducers.
>> #{"threaded":true,"repeat":true,"procs":6,"sandbox":"","fault_call":-1,"tmpdir":true}
>> r0 = openat$kvm(0xffffffffffffff9c, &(0x7f0000000080)='/dev/kvm\x00', 0x0, 0x0)
>> r1 = ioctl$KVM_CREATE_VM(r0, 0xae01, 0x0)
>> r2 = ioctl$KVM_CREATE_VCPU(r1, 0xae41, 0x0)
>> ioctl$KVM_SET_VCPU_EVENTS(r2, 0x4040aea0, &(0x7f0000000000)={0x5, 0x7, 0x40, 0x0, 0x0, 0x0, 0x0, 0x492, 0x5, 0x1, 0xffff, 0x0, 0x0, 0xef, 0x100000000, 0x0, 0x100})
>> ioctl$KVM_SET_USER_MEMORY_REGION(r1, 0x4020ae46, &(0x7f0000000040)={0x0, 0x0, 0x0, 0x2000, &(0x7f0000ffe000/0x2000)=nil})
>> ioctl$KVM_SET_SREGS(r2, 0x4138ae84, &(0x7f00000003c0)={{}, {}, {}, {}, {}, {}, {}, {}, {}, {}, 0x8005001f, 0x0, 0x0, 0x28, 0x0, 0x6500})
>> ioctl$KVM_RUN(r2, 0xae80, 0x0)