* NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs
@ 2016-02-19 14:06 Robert Święcki
2016-02-19 16:29 ` Robert Święcki
2016-08-18 11:58 ` Paolo Bonzini
0 siblings, 2 replies; 9+ messages in thread
From: Robert Święcki @ 2016-02-19 14:06 UTC (permalink / raw)
To: LKML; +Cc: Dmitry Vyukov, Paolo Bonzini, Borislav Petkov
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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs 2016-02-19 14:06 NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs Robert Święcki @ 2016-02-19 16:29 ` Robert Święcki 2016-08-18 11:58 ` Paolo Bonzini 1 sibling, 0 replies; 9+ messages in thread From: Robert Święcki @ 2016-02-19 16:29 UTC (permalink / raw) To: LKML; +Cc: Dmitry Vyukov, Paolo Bonzini, Borislav Petkov > ==== > // 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs 2016-02-19 14:06 NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs Robert Święcki 2016-02-19 16:29 ` Robert Święcki @ 2016-08-18 11:58 ` Paolo Bonzini 2016-08-19 0:16 ` Dmitry Vyukov 1 sibling, 1 reply; 9+ messages in thread From: Paolo Bonzini @ 2016-08-18 11:58 UTC (permalink / raw) To: Robert Święcki, LKML; +Cc: Dmitry Vyukov, Borislav Petkov 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 > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs 2016-08-18 11:58 ` Paolo Bonzini @ 2016-08-19 0:16 ` Dmitry Vyukov 2016-08-29 12:02 ` Paolo Bonzini 0 siblings, 1 reply; 9+ messages in thread From: Dmitry Vyukov @ 2016-08-19 0:16 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Robert Święcki, LKML, Borislav Petkov 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs 2016-08-19 0:16 ` Dmitry Vyukov @ 2016-08-29 12:02 ` Paolo Bonzini 2016-08-30 13:08 ` Dmitry Vyukov 0 siblings, 1 reply; 9+ messages in thread From: Paolo Bonzini @ 2016-08-29 12:02 UTC (permalink / raw) To: Dmitry Vyukov; +Cc: Robert Święcki, LKML, Borislav Petkov 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs 2016-08-29 12:02 ` Paolo Bonzini @ 2016-08-30 13:08 ` Dmitry Vyukov 2016-08-30 15:03 ` Paolo Bonzini 0 siblings, 1 reply; 9+ messages in thread From: Dmitry Vyukov @ 2016-08-30 13:08 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Robert Święcki, LKML, Borislav Petkov 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs 2016-08-30 13:08 ` Dmitry Vyukov @ 2016-08-30 15:03 ` Paolo Bonzini 2016-09-09 23:03 ` Dmitry Vyukov 0 siblings, 1 reply; 9+ messages in thread From: Paolo Bonzini @ 2016-08-30 15:03 UTC (permalink / raw) To: Dmitry Vyukov; +Cc: Robert Święcki, LKML, Borislav Petkov 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs 2016-08-30 15:03 ` Paolo Bonzini @ 2016-09-09 23:03 ` Dmitry Vyukov 2016-09-10 6:43 ` Paolo Bonzini 0 siblings, 1 reply; 9+ messages in thread From: Dmitry Vyukov @ 2016-09-09 23:03 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Robert Święcki, LKML, Borislav Petkov 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? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs 2016-09-09 23:03 ` Dmitry Vyukov @ 2016-09-10 6:43 ` Paolo Bonzini 0 siblings, 0 replies; 9+ messages in thread From: Paolo Bonzini @ 2016-09-10 6:43 UTC (permalink / raw) To: Dmitry Vyukov; +Cc: Robert Święcki, LKML, Borislav Petkov > > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2016-09-10 6:44 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-02-19 14:06 NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs Robert Święcki 2016-02-19 16:29 ` Robert Święcki 2016-08-18 11:58 ` Paolo Bonzini 2016-08-19 0:16 ` Dmitry Vyukov 2016-08-29 12:02 ` Paolo Bonzini 2016-08-30 13:08 ` Dmitry Vyukov 2016-08-30 15:03 ` Paolo Bonzini 2016-09-09 23:03 ` Dmitry Vyukov 2016-09-10 6:43 ` Paolo Bonzini
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).