NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs

NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs

[Robert Święcki]

Hi,

This seems non-exploitable due to mmap_min_addr, so I guess it should
be treated just as a regular bug

Tested with 4.5-rc4 and with 4.4 under Opteron 6272 and FX-8320

[167193.153283] BUG: unable to handle kernel NULL pointer dereference
at 00000000000000f0
[167193.153372] IP: [<ffffffffc0545067>] kvm_arch_vcpu_ioctl+0x417/0x1120 [kvm]
[167193.153453] PGD fca0067 PUD 79907067 PMD 0
[167193.153503] Oops: 0000 [#1] SMP
[167193.153571] Modules linked in: binfmt_misc nls_utf8 btrfs xor
raid6_pq ufs qnx4 hfsplus hfs minix ntfs msdos jfs xfs libcrc32c
kvm_amd amd64_edac_mod input_leds joydev kvm snd_pcm snd_timer
edac_mce_amd edac_core snd i2c_piix4 irqbypass fam15h_power
tpm_infineon shpchp k10temp crct10dif_pclmul crc32_pclmul aesni_intel
psmouse evbug soundcore aes_x86_64 mac_hid lrw 8250_fintek gf128mul
serio_raw glue_helper pcspkr ablk_helper cryptd ipmi_ssif
ipmi_watchdog ipmi_si ipmi_poweroff ipmi_devintf ipmi_msghandler
autofs4 pata_acpi hid_generic usbkbd usbmouse usbhid hid igb
i2c_algo_bit dca ahci ptp pata_atiixp libahci pps_core fjes
[167193.154119] CPU: 3 PID: 22154 Comm: z Not tainted 4.4.0-4-generic #19-Ubuntu
[167193.154173] Hardware name: HP ProLiant DL165 G7, BIOS O37 02/02/2012
[167193.154224] task: ffff8801fe899b80 ti: ffff88005ff30000 task.ti:
ffff88005ff30000
[167193.154304] RIP: 0010:[<ffffffffc0545067>]  [<ffffffffc0545067>]
kvm_arch_vcpu_ioctl+0x417/0x1120 [kvm]
[167193.154397] RSP: 0018:ffff88005ff33d28  EFLAGS: 00010246
[167193.154445] RAX: 0000000000000000 RBX: ffffffffffffffea RCX:
0000000000000176
[167193.154523] RDX: 0000000000000000 RSI: 000000008040ae9f RDI:
ffff880075eebe80
[167193.154601] RBP: ffff88005ff33e00 R08: 0000000000000000 R09:
0000000000000000
[167193.154684] R10: 0000000000000000 R11: 0000000000000212 R12:
0000000020010fef
[167193.154785] R13: 0000000000000000 R14: ffff880075eebe80 R15:
0000000000000000
[167193.154864] FS:  00007f00c9d7b700(0000) GS:ffff88007dcc0000(0000)
knlGS:0000000000000000
[167193.154945] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[167193.154994] CR2: 00000000000000f0 CR3: 0000000078982000 CR4:
00000000000406e0
[167193.155077] Stack:
[167193.155112]  ffffffff810e9ca1 0000000000000086 0000000050045e40
0000000000000003
[167193.155199]  ffff880000105200 0000000000000000 0000000000000000
ffff880000000000
[167193.155286]  ffff88005f000000 ffffffffc0249a63 0000000075eebe80
0000000050045e40
[167193.155373] Call Trace:
[167193.155417]  [<ffffffff810e9ca1>] ? add_timer_on+0xf1/0x160
[167193.155469]  [<ffffffffc0249a63>] ? svm_vcpu_load+0x83/0x110 [kvm_amd]
[167193.155536]  [<ffffffffc0544a8a>] ? kvm_arch_vcpu_load+0x5a/0x220 [kvm]
[167193.155600]  [<ffffffffc0531de7>] kvm_vcpu_ioctl+0xe7/0x5f0 [kvm]
[167193.155653]  [<ffffffff81251952>] ? anon_inode_getfd+0x52/0x80
[167193.155713]  [<ffffffffc0530db0>] ? kvm_dev_ioctl+0x140/0x4a0 [kvm]
[167193.155766]  [<ffffffff8121b108>] do_vfs_ioctl+0x298/0x480
[167193.155815]  [<ffffffff81216e64>] ? putname+0x54/0x60
[167193.155863]  [<ffffffff81206dbf>] ? do_sys_open+0x1bf/0x280
[167193.155913]  [<ffffffff8121b369>] SyS_ioctl+0x79/0x90
[167193.155984]  [<ffffffff81811f32>] entry_SYSCALL_64_fastpath+0x16/0x71
[167193.156035] Code: e0 01 83 e2 01 88 95 68 ff ff ff 41 0f b6 96 39
32 00 00 88 85 6a ff ff ff 88 95 69 ff ff ff 0f 1f 44 00 00 49 8b 86
a0 02 00 00 <48> 8b 80 f0 00 00 00 83 e0 01 88 85 6b ff ff ff c7 85 64
ff ff
[167193.156326] RIP  [<ffffffffc0545067>] kvm_arch_vcpu_ioctl+0x417/0x1120 [kvm]
[167193.156391]  RSP <ffff88005ff33d28>
[167193.156432] CR2: 00000000000000f0
[167193.156840] ---[ end trace 3ff15297044194ff ]---


====
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include <unistd.h>
#include <sys/syscall.h>
#include <string.h>
#include <stdint.h>
#include <pthread.h>

long r[6];

int main()
{
memset(r, -1, sizeof(r));
r[0] = syscall(SYS_mmap, 0x20000000ul, 0x13000ul, 0x3ul, 0x32ul,
0xfffffffffffffffful, 0x0ul);
memcpy((void*)0x2000eedb, "\x2f\x64\x65\x76\x2f\x6b\x76\x6d", 8);
r[2] = syscall(SYS_open, 0x2000eedbul, 0x0ul, 0x100ul, 0, 0, 0);
r[3] = syscall(SYS_ioctl, r[2], 0xae01ul, 0x0ul, 0, 0, 0);
r[4] = syscall(SYS_ioctl, r[3], 0xae41ul, 0x7ul, 0, 0, 0);
r[5] = syscall(SYS_ioctl, r[4], 0x8040ae9ful, 0x20010feful, 0, 0, 0);
return 0;
}
====

strace:

open("/dev/kvm", O_RDONLY)              = 3
ioctl(3, KVM_CREATE_VM, 0)              = 4
ioctl(4, KVM_CREATE_VCPU, 0x7)          = 5
ioctl(5, KVM_GET_PIT2 or KVM_GET_VCPU_EVENTS, 0x20010fef) = 0

Should be run in parallel (try increasing 10 to 100 or so, if this doesn't work)

$ for x in `seq 1 10`; do { ./prog & }; done

-- 
Robert Święcki

Re: NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs

[Robert Święcki]

> ====
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include <unistd.h>
> #include <sys/syscall.h>
> #include <string.h>
> #include <stdint.h>
> #include <pthread.h>
>
> long r[6];
>
> int main()
> {
> memset(r, -1, sizeof(r));
> r[0] = syscall(SYS_mmap, 0x20000000ul, 0x13000ul, 0x3ul, 0x32ul,
> 0xfffffffffffffffful, 0x0ul);
> memcpy((void*)0x2000eedb, "\x2f\x64\x65\x76\x2f\x6b\x76\x6d", 8);
> r[2] = syscall(SYS_open, 0x2000eedbul, 0x0ul, 0x100ul, 0, 0, 0);
> r[3] = syscall(SYS_ioctl, r[2], 0xae01ul, 0x0ul, 0, 0, 0);
> r[4] = syscall(SYS_ioctl, r[3], 0xae41ul, 0x7ul, 0, 0, 0);
> r[5] = syscall(SYS_ioctl, r[4], 0x8040ae9ful, 0x20010feful, 0, 0, 0);
> return 0;
> }
> ====
>
> strace:
>
> open("/dev/kvm", O_RDONLY)              = 3
> ioctl(3, KVM_CREATE_VM, 0)              = 4
> ioctl(4, KVM_CREATE_VCPU, 0x7)          = 5
> ioctl(5, KVM_GET_PIT2 or KVM_GET_VCPU_EVENTS, 0x20010fef) = 0
>
> Should be run in parallel (try increasing 10 to 100 or so, if this doesn't work)
>
> $ for x in `seq 1 10`; do { ./prog & }; done

Here's a very similar one, but it works *inside* qemu, with nested
virtualization enabled (AMD SVM). It hits another symbol in the
kernel, but the general idea is the same. Run this binary ~100 times
in parallel. Tested with host: 4.4 and guest 4.4 and 4.5-rc4 on host
CPU Opteron 6272

=================
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include <unistd.h>
#include <sys/syscall.h>
#include <string.h>
#include <stdint.h>
#include <pthread.h>

#ifndef SYS_mmap
#define SYS_mmap 9
#endif
#ifndef SYS_syz_open_dev
#define SYS_syz_open_dev 1000001
#endif
#ifndef SYS_ioctl
#define SYS_ioctl 16
#endif

long r[6];

int main()
{
memset(r, -1, sizeof(r));
r[0] = syscall(SYS_mmap, 0x20000000ul, 0xf000ul, 0x3ul, 0x32ul,
0xfffffffffffffffful, 0x0ul);
memcpy((void*)0x2000173f, "\x2f\x64\x65\x76\x2f\x6b\x76\x6d", 8);
r[2] = syscall(SYS_open, 0x2000173ful, 0x0ul, 0x100ul, 0, 0, 0);
r[3] = syscall(SYS_ioctl, r[2], 0xae01ul, 0x0ul, 0, 0, 0);
r[4] = syscall(SYS_ioctl, r[3], 0xae41ul, 0x8ul, 0, 0, 0);
r[5] = syscall(SYS_ioctl, r[4], 0x8004ae98ul, 0x20007000ul, 0, 0, 0);
return 0;
}
=================

strace:
open("/dev/kvm", O_RDONLY)              = 3
ioctl(3, KVM_CREATE_VM, 0)              = 4
ioctl(4, KVM_CREATE_VCPU, 0x8)          = 5
ioctl(5, KVM_GET_MP_STATE, 0x20007000)  = 0

Run as: for x in `seq 1 40`; do { ./prog & }; done

[  162.697592] kvm: Nested Virtualization enabled
[  218.733272] BUG: unable to handle kernel NULL pointer dereference
at 00000000000000f0
[  218.733309] IP: [<ffffffffa025e34a>] kvm_apic_accept_events+0x2a/0x150 [kvm]
[  218.733312] PGD d4a1067 PUD f7b8067 PMD 0
[  218.733314] Oops: 0000 [#1] SMP
[  218.733325] Modules linked in: kvm_amd kvm ext4 crc16 mbcache jbd2
sg sr_mod cdrom sd_mod ata_generic uhci_hcd ehci_hcd ata_piix usbcore
e1000 libata usb_common scsi_mod floppy
[  218.733328] CPU: 1 PID: 2106 Comm: y Not tainted
4.3.0-0.bpo.1-amd64 #1 Debian 4.3.3-7~bpo8+1
[  218.733329] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[  218.733330] task: ffff88001f97e3c0 ti: ffff88001f9c8000 task.ti:
ffff88001f9c8000
[  218.733351] RIP: 0010:[<ffffffffa025e34a>]  [<ffffffffa025e34a>]
kvm_apic_accept_events+0x2a/0x150 [kvm]
[  218.733353] RSP: 0018:ffff88001f9cbdf0  EFLAGS: 00010246
[  218.733354] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000100000000
[  218.733355] RDX: ffff88000da65000 RSI: ffff88001f9cbe30 RDI: ffff88000ea18100
[  218.733356] RBP: ffff88000ea18100 R08: 0000000000000000 R09: 0000000000000000
[  218.733357] R10: 0000000000000000 R11: 0000000000000203 R12: 000000008004ae98
[  218.733358] R13: 0000000020007000 R14: ffff88000d48bb00 R15: 0000000020007000
[  218.733362] FS:  00007fb33aba2700(0000) GS:ffff88000f900000(0000)
knlGS:0000000000000000
[  218.733363] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  218.733365] CR2: 00000000000000f0 CR3: 000000000f7bb000 CR4: 00000000000006e0
[  218.733369] Stack:
[  218.733372]  ffff88000ea18100 00000000a9f3a679 ffff88000ea18100
ffff88001f9cbe30
[  218.733374]  ffffffffa0240172 ffffffffffffffea ffff88000ea18100
ffffffffa022c63c
[  218.733376]  ffff88000ea14000 ffffffff8121705b ffff88000ea14000
ffff88000ea14a30
[  218.733377] Call Trace:
[  218.733396]  [<ffffffffa0240172>] ?
kvm_arch_vcpu_ioctl_get_mpstate+0x12/0x40 [kvm]
[  218.733410]  [<ffffffffa022c63c>] ? kvm_vcpu_ioctl+0xfc/0x5a0 [kvm]
[  218.733414]  [<ffffffff8121705b>] ? anon_inode_getfd+0x4b/0x70
[  218.733427]  [<ffffffffa022b70f>] ? kvm_dev_ioctl+0x11f/0x450 [kvm]
[  218.733432]  [<ffffffff811e3255>] ? do_vfs_ioctl+0x2d5/0x4b0
[  218.733435]  [<ffffffff811e34a6>] ? SyS_ioctl+0x76/0x90
[  218.733439]  [<ffffffff8158a3f6>] ? system_call_fast_compare_end+0xc/0x6b
[  218.733460] Code: 00 66 66 66 66 90 55 53 48 89 fd 48 83 ec 10 48
8b 9f a0 02 00 00 65 48 8b 04 25 28 00 00 00 48 89 44 24 08 31 c0 66
66 66 66 90 <48> 83 bb f0 00 00 00 00 75 22 48 8b 44 24 08 65 48 33 04
25 28

-- 
Robert Święcki

Re: NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs

[Paolo Bonzini]

On 19/02/2016 15:06, Robert Święcki wrote:
> Hi,
> 
> 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!

Paolo

> Tested with 4.5-rc4 and with 4.4 under Opteron 6272 and FX-8320
> 
> [167193.153283] BUG: unable to handle kernel NULL pointer dereference
> at 00000000000000f0
> [167193.153372] IP: [<ffffffffc0545067>] kvm_arch_vcpu_ioctl+0x417/0x1120 [kvm]
> [167193.153453] PGD fca0067 PUD 79907067 PMD 0
> [167193.153503] Oops: 0000 [#1] SMP
> [167193.153571] Modules linked in: binfmt_misc nls_utf8 btrfs xor
> raid6_pq ufs qnx4 hfsplus hfs minix ntfs msdos jfs xfs libcrc32c
> kvm_amd amd64_edac_mod input_leds joydev kvm snd_pcm snd_timer
> edac_mce_amd edac_core snd i2c_piix4 irqbypass fam15h_power
> tpm_infineon shpchp k10temp crct10dif_pclmul crc32_pclmul aesni_intel
> psmouse evbug soundcore aes_x86_64 mac_hid lrw 8250_fintek gf128mul
> serio_raw glue_helper pcspkr ablk_helper cryptd ipmi_ssif
> ipmi_watchdog ipmi_si ipmi_poweroff ipmi_devintf ipmi_msghandler
> autofs4 pata_acpi hid_generic usbkbd usbmouse usbhid hid igb
> i2c_algo_bit dca ahci ptp pata_atiixp libahci pps_core fjes
> [167193.154119] CPU: 3 PID: 22154 Comm: z Not tainted 4.4.0-4-generic #19-Ubuntu
> [167193.154173] Hardware name: HP ProLiant DL165 G7, BIOS O37 02/02/2012
> [167193.154224] task: ffff8801fe899b80 ti: ffff88005ff30000 task.ti:
> ffff88005ff30000
> [167193.154304] RIP: 0010:[<ffffffffc0545067>]  [<ffffffffc0545067>]
> kvm_arch_vcpu_ioctl+0x417/0x1120 [kvm]
> [167193.154397] RSP: 0018:ffff88005ff33d28  EFLAGS: 00010246
> [167193.154445] RAX: 0000000000000000 RBX: ffffffffffffffea RCX:
> 0000000000000176
> [167193.154523] RDX: 0000000000000000 RSI: 000000008040ae9f RDI:
> ffff880075eebe80
> [167193.154601] RBP: ffff88005ff33e00 R08: 0000000000000000 R09:
> 0000000000000000
> [167193.154684] R10: 0000000000000000 R11: 0000000000000212 R12:
> 0000000020010fef
> [167193.154785] R13: 0000000000000000 R14: ffff880075eebe80 R15:
> 0000000000000000
> [167193.154864] FS:  00007f00c9d7b700(0000) GS:ffff88007dcc0000(0000)
> knlGS:0000000000000000
> [167193.154945] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [167193.154994] CR2: 00000000000000f0 CR3: 0000000078982000 CR4:
> 00000000000406e0
> [167193.155077] Stack:
> [167193.155112]  ffffffff810e9ca1 0000000000000086 0000000050045e40
> 0000000000000003
> [167193.155199]  ffff880000105200 0000000000000000 0000000000000000
> ffff880000000000
> [167193.155286]  ffff88005f000000 ffffffffc0249a63 0000000075eebe80
> 0000000050045e40
> [167193.155373] Call Trace:
> [167193.155417]  [<ffffffff810e9ca1>] ? add_timer_on+0xf1/0x160
> [167193.155469]  [<ffffffffc0249a63>] ? svm_vcpu_load+0x83/0x110 [kvm_amd]
> [167193.155536]  [<ffffffffc0544a8a>] ? kvm_arch_vcpu_load+0x5a/0x220 [kvm]
> [167193.155600]  [<ffffffffc0531de7>] kvm_vcpu_ioctl+0xe7/0x5f0 [kvm]
> [167193.155653]  [<ffffffff81251952>] ? anon_inode_getfd+0x52/0x80
> [167193.155713]  [<ffffffffc0530db0>] ? kvm_dev_ioctl+0x140/0x4a0 [kvm]
> [167193.155766]  [<ffffffff8121b108>] do_vfs_ioctl+0x298/0x480
> [167193.155815]  [<ffffffff81216e64>] ? putname+0x54/0x60
> [167193.155863]  [<ffffffff81206dbf>] ? do_sys_open+0x1bf/0x280
> [167193.155913]  [<ffffffff8121b369>] SyS_ioctl+0x79/0x90
> [167193.155984]  [<ffffffff81811f32>] entry_SYSCALL_64_fastpath+0x16/0x71
> [167193.156035] Code: e0 01 83 e2 01 88 95 68 ff ff ff 41 0f b6 96 39
> 32 00 00 88 85 6a ff ff ff 88 95 69 ff ff ff 0f 1f 44 00 00 49 8b 86
> a0 02 00 00 <48> 8b 80 f0 00 00 00 83 e0 01 88 85 6b ff ff ff c7 85 64
> ff ff
> [167193.156326] RIP  [<ffffffffc0545067>] kvm_arch_vcpu_ioctl+0x417/0x1120 [kvm]
> [167193.156391]  RSP <ffff88005ff33d28>
> [167193.156432] CR2: 00000000000000f0
> [167193.156840] ---[ end trace 3ff15297044194ff ]---
> 
> 
> ====
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include <unistd.h>
> #include <sys/syscall.h>
> #include <string.h>
> #include <stdint.h>
> #include <pthread.h>
> 
> long r[6];
> 
> int main()
> {
> memset(r, -1, sizeof(r));
> r[0] = syscall(SYS_mmap, 0x20000000ul, 0x13000ul, 0x3ul, 0x32ul,
> 0xfffffffffffffffful, 0x0ul);
> memcpy((void*)0x2000eedb, "\x2f\x64\x65\x76\x2f\x6b\x76\x6d", 8);
> r[2] = syscall(SYS_open, 0x2000eedbul, 0x0ul, 0x100ul, 0, 0, 0);
> r[3] = syscall(SYS_ioctl, r[2], 0xae01ul, 0x0ul, 0, 0, 0);
> r[4] = syscall(SYS_ioctl, r[3], 0xae41ul, 0x7ul, 0, 0, 0);
> r[5] = syscall(SYS_ioctl, r[4], 0x8040ae9ful, 0x20010feful, 0, 0, 0);
> return 0;
> }
> ====
> 
> strace:
> 
> open("/dev/kvm", O_RDONLY)              = 3
> ioctl(3, KVM_CREATE_VM, 0)              = 4
> ioctl(4, KVM_CREATE_VCPU, 0x7)          = 5
> ioctl(5, KVM_GET_PIT2 or KVM_GET_VCPU_EVENTS, 0x20010fef) = 0
> 
> Should be run in parallel (try increasing 10 to 100 or so, if this doesn't work)
> 
> $ for x in `seq 1 10`; do { ./prog & }; done
> 

Re: NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs

[Dmitry Vyukov]

On Thu, Aug 18, 2016 at 4:58 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>
> On 19/02/2016 15:06, Robert Święcki wrote:
>> Hi,
>>
>> 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

Re: NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs

[Paolo Bonzini]

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

Re: NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs

[Dmitry Vyukov]

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.

Re: NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs

[Paolo Bonzini]

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

Re: NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs

[Dmitry Vyukov]

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?

Re: NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs

[Paolo Bonzini]

> 
> 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