Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1471756 > unrolled thread

Re: NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs Paolo Bonzini <pbonzini@redhat.com> - 2016-08-29 14:10 +0200
    Re: NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs Dmitry Vyukov <dvyukov@google.com> - 2016-08-30 15:10 +0200
      Re: NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs Paolo Bonzini <pbonzini@redhat.com> - 2016-08-30 17:10 +0200
        Re: NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs Dmitry Vyukov <dvyukov@google.com> - 2016-09-10 01:10 +0200
          Re: NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs Paolo Bonzini <pbonzini@redhat.com> - 2016-09-10 08:50 +0200

#1471756 — 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

[toc] | [next] | [standalone]

#1472476

On Mon, Aug 29, 2016 at 2:02 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> 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.


I've started fuzzing kvm again. No crashes so far.

[toc] | [prev] | [next] | [standalone]

#1472545

On 30/08/2016 15:08, Dmitry Vyukov wrote:
>> > 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.
> 
> I've started fuzzing kvm again. No crashes so far.

Fingers crossed! :)

Paolo

[toc] | [prev] | [next] | [standalone]

#1480432

On Tue, Aug 30, 2016 at 5:03 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>
> On 30/08/2016 15:08, Dmitry Vyukov wrote:
>>> > 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.
>>
>> I've started fuzzing kvm again. No crashes so far.
>
> Fingers crossed! :)


Hi Paolo,

I've noticed that KVM is not actually enabled on my machines. /dev/kvm
is missing. If I mknod it manually, opens return ENODEV.
After several hours of debugging I figured that it seems to be caused by:

commit 91fa0f8e9e2937fd9360f326ad60d51908347afd
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Wed Jun 15 20:55:08 2016 +0200
    KVM: x86: always use "acknowledge interrupt on exit"

If I move VM_EXIT_ACK_INTR_ON_EXIT from min back to opt. /dev/kvm
become functional again (at least I can open it).

To make it clear, it all happens inside of qemu instance. I've tried
using different cpus in qemu, including "host" cpu which is pretty
capable:

model name : Intel(R) Xeon(R) CPU E5-2690 v3 @ 2.60GHz
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm
constant_tsc arch_perfmon rep_good nopl eagerfpu pni pclmulqdq vmx
ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt
tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm
vnmi ept fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt

So why am I missing VM_EXIT_ACK_INTR_ON_EXIT feature? How does it work
for other users? And how should I fix it in a proper way?

[toc] | [prev] | [next] | [standalone]

#1480513

> 
> Hi Paolo,
> 
> I've noticed that KVM is not actually enabled on my machines. /dev/kvm
> is missing. If I mknod it manually, opens return ENODEV.
> After several hours of debugging I figured that it seems to be caused by:
> 
> commit 91fa0f8e9e2937fd9360f326ad60d51908347afd
> Author: Paolo Bonzini <pbonzini@redhat.com>
> Date:   Wed Jun 15 20:55:08 2016 +0200
>     KVM: x86: always use "acknowledge interrupt on exit"
> 
> If I move VM_EXIT_ACK_INTR_ON_EXIT from min back to opt. /dev/kvm
> become functional again (at least I can open it).
> 
> To make it clear, it all happens inside of qemu instance. I've tried
> using different cpus in qemu, including "host" cpu which is pretty
> capable:
> 
> model name : Intel(R) Xeon(R) CPU E5-2690 v3 @ 2.60GHz
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
> pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm
> constant_tsc arch_perfmon rep_good nopl eagerfpu pni pclmulqdq vmx
> ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt
> tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm
> vnmi ept fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt
> 
> So why am I missing VM_EXIT_ACK_INTR_ON_EXIT feature? How does it work
> for other users? And how should I fix it in a proper way?

You need to upgrade your host kernel to 3.16 (or possibly 3.17, but I
think it's 3.16).  This is a virtualization feature, and it is not
provided by the processor (as is the case for "-cpu host" features);
it's provided by the host kernel.

Thanks,

Paolo

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web