linux-kernel - Re: NULL-ptr deref in kvm_arch_vcpu

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]

Date:   Mon, 29 Aug 2016 14:02:18 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     Robert Święcki <robert@...ecki.net>,
        LKML <linux-kernel@...r.kernel.org>,
        Borislav Petkov <bp@...en8.de>
Subject: Re: NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs



On 19/08/2016 02:16, Dmitry Vyukov wrote:
> > > This seems non-exploitable due to mmap_min_addr, so I guess it should
> > > be treated just as a regular bug
> >
> > Probably fixed by commit 4c5ea0a9cd02 ("locking/static_key: Fix
> > concurrent static_key_slow_inc()", 2016-06-21).  There should be no
> > outstanding syzkaller reports for KVM now!
>
> Thanks for the update. I will try to reenable kvm fuzzing on my
> syzkaller instances.
> Just to make sure, you mean all bugs prefixed with kvm: here, right?
> https://github.com/google/syzkaller/wiki/Found-Bugs

Yes.  These are the relevant commits:

b21629da120   kvm: x86: avoid warning on repeated KVM_SET_TSS_ADDR
83676e92389   KVM: x86: avoid vmalloc(0) in the KVM_SET_CPUID
78e546c824f   KVM: fail KVM_SET_VCPU_EVENTS with invalid exception number
c622a3c21ed   KVM: irqfd: fix NULL pointer dereference in kvm_irq_map_gsi
f8c1b85b252   KVM: x86: avoid vmalloc(0) in the KVM_SET_CPUID
d14bdb553f9   KVM: x86: fix OOPS after invalid KVM_SET_DEBUGREGS
250715a6171   KVM: x86: protect KVM_CREATE_PIT/KVM_CREATE_PIT2 with kvm->lock
4c5ea0a9cd0   locking/static_key: Fix concurrent static_key_slow_inc()

The last one is responsible for most if not all of the OOPses with
threads.

Paolo