Re: kvm: WARNING in exception_type

[Nadav Amit]

Without actual debugging, it appears that kvm_vcpu_ioctl_x86_set_vcpu_events
does not check the events data-structure before copying it to
vcpu->arch.exception and vcpu->arch.interrupt. It therefore does not check
that the exception number is correct (x<31 && x!=2) among other missing
checks.

Regards,
Nadav

Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:

> 
> 
> On 15/01/2016 18:11, Dmitry Vyukov wrote:
>> 2016-01-08 16:42 GMT+01:00 Dmitry Vyukov <dvyukov@xxxxxxxxxx>:
>>> Hello,
>>> The following program triggers WARNING in exception_type:
>>> 
>>> // autogenerated by syzkaller (http://github.com/google/syzkaller)
>>> #include <unistd.h>
>>> #include <sys/syscall.h>
>>> #include <string.h>
>>> #include <stdint.h>
>>> 
>>> long r[31];
>>> 
>>> int main()
>>> {
>>>        memset(r, -1, sizeof(r));
>>>        r[0] = syscall(SYS_mmap, 0x20000000ul, 0x20000ul, 0x3ul,
>>> 0x32ul, 0xfffffffffffffffful, 0x0ul);
>>>        memcpy((void*)0x20004000, "\x2f\x64\x65\x76\x2f\x6b\x76\x6d", 8);
>>>        r[2] = syscall(SYS_open, 0x20004000ul, 0x0ul, 0x0ul, 0, 0, 0);
>>>        r[3] = syscall(SYS_ioctl, r[2], 0xae01ul, 0x0ul, 0, 0, 0);
>>>        *(uint32_t*)0x2000fff8 = (uint32_t)0x8;
>>>        *(uint32_t*)0x2000fffc = (uint32_t)0xae84;
>>>        r[6] = syscall(SYS_ioctl, r[3], 0x4008ae61ul, 0x2000fff8ul, 0, 0, 0);
>>>        r[7] = syscall(SYS_ioctl, r[3], 0xae41ul, 0x0ul, 0, 0, 0);
>>>        *(uint8_t*)0x20011e0f = (uint8_t)0x9;
>>>        *(uint8_t*)0x20011e10 = (uint8_t)0x9d4;
>>>        *(uint8_t*)0x20011e11 = (uint8_t)0x9;
>>>        *(uint8_t*)0x20011e12 = (uint8_t)0x8;
>>>        *(uint32_t*)0x20011e13 = (uint32_t)0x1;
>>>        *(uint8_t*)0x20011e17 = (uint8_t)0x5;
>>>        *(uint8_t*)0x20011e18 = (uint8_t)0x482;
>>>        *(uint8_t*)0x20011e19 = (uint8_t)0x0;
>>>        *(uint8_t*)0x20011e1a = (uint8_t)0x5;
>>>        *(uint8_t*)0x20011e1b = (uint8_t)0x6;
>>>        *(uint8_t*)0x20011e1c = (uint8_t)0x1;
>>>        *(uint8_t*)0x20011e1d = (uint8_t)0xf382;
>>>        *(uint8_t*)0x20011e1e = (uint8_t)0x1b5;
>>>        *(uint32_t*)0x20011e1f = (uint32_t)0x9;
>>>        *(uint32_t*)0x20011e23 = (uint32_t)0x3;
>>>        *(uint8_t*)0x20011e27 = (uint8_t)0x1;
>>>        *(uint8_t*)0x20011e28 = (uint8_t)0x5;
>>>        *(uint8_t*)0x20011e29 = (uint8_t)0x6;
>>>        *(uint8_t*)0x20011e2a = (uint8_t)0x0;
>>>        r[27] = syscall(SYS_ioctl, r[7], 0x4040aea0ul, 0x20011e0ful, 0, 0, 0);
>>>        memcpy((void*)0x20012f83,
>>> "\x29\xac\x42\x56\xbf\x67\x61\x4f\x07\xb8\xde\x10\x83\x05\x7b\x55\x68\x42\xcb\x36\x97\x84\xff\x6a\x69\x10\x05\x63\xb0\x27\xa5\xbf\xe8\x7b\xe2\xe8\x73\x5d\x7a\x1f\x9f\x48\x9a\xc6\xdf\x4e\x6f\xdd\xb2\xbe\x06\x5c\x2c\x3f\xa7\xf7\x6c\xb7\x02\x9e\x7c\x27\x47\x53\xc0\x4f\xe3\xcd\x7e\xe0\xcb\xe2\x57\xbb\x54\x99\xb0\xac\x01\x6a\x99\xd5\x3d\x95\x3f\x78\x07\xa8\xf2\xf1\x57\x1e\x02\x85\x52\xbb\x53\x8e\x63\x45\x86\x23\xf5\xcb\x04\x40\x5b\xe8\x4b\x22\x1e\xbe\xff\x01\xe6\x1c\x95\x15\xb5\x4a\x37\xa7\x4c\xf4\x3e",
>>> 125);
>>>        r[29] = syscall(SYS_ioctl, r[7], 0x4138ae84ul, 0x20012f83ul, 0, 0, 0);
>>>        r[30] = syscall(SYS_ioctl, r[7], 0xae80ul, 0, 0, 0, 0);
>>>        return 0;
>>> }
>>> 
>>> 
>>> ------------[ cut here ]------------
>>> WARNING: CPU: 1 PID: 10173 at arch/x86/kvm/x86.c:345 exception_type+0x73/0x80()
>>> Modules linked in:
>>> CPU: 1 PID: 10173 Comm: a.out Tainted: G        W       4.4.0-rc8+ #211
>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>>> 00000000ffffffff ffff880035347a08 ffffffff82907ccd 0000000000000000
>>> ffff880033f82f00 ffffffff85ed4540 ffff880035347a48 ffffffff8133f979
>>> ffffffff81036893 ffffffff85ed4540 0000000000000159 ffff880034138030
>>> Call Trace:
>>> [<     inline     >] __dump_stack lib/dump_stack.c:15
>>> [<ffffffff82907ccd>] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
>>> [<ffffffff8133f979>] warn_slowpath_common+0xd9/0x140 kernel/panic.c:460
>>> [<ffffffff8133fba9>] warn_slowpath_null+0x29/0x30 kernel/panic.c:493
>>> [<ffffffff81036893>] exception_type+0x73/0x80 arch/x86/kvm/x86.c:345
>>> [<     inline     >] inject_pending_event arch/x86/kvm/x86.c:5990
>>> [<     inline     >] vcpu_enter_guest arch/x86/kvm/x86.c:6471
>>> [<     inline     >] vcpu_run arch/x86/kvm/x86.c:6660
>>> [<ffffffff8106b1c4>] kvm_arch_vcpu_ioctl_run+0x3554/0x5800
>>> arch/x86/kvm/x86.c:6818
>>> [<ffffffff8101cf61>] kvm_vcpu_ioctl+0x5f1/0xd00
>>> arch/x86/kvm/../../../virt/kvm/kvm_main.c:2375
>>> [<     inline     >] vfs_ioctl fs/ioctl.c:43
>>> [<ffffffff817b66f1>] do_vfs_ioctl+0x681/0xe40 fs/ioctl.c:607
>>> [<     inline     >] SYSC_ioctl fs/ioctl.c:622
>>> [<ffffffff817b6f3f>] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:613
>>> [<ffffffff85e77af6>] entry_SYSCALL_64_fastpath+0x16/0x7a
>>> arch/x86/entry/entry_64.S:185
>>> ---[ end trace 6d1cb7e02f8364e9 ]---
>>> 
>>> 
>>> On commit b06f3a168cdcd80026276898fd1fee443ef25743 (Jan 6).
>> 
>> + more kvm people
> 
> No need for.  It's just that I'm busy and, while I appreciate your
> reports, they take a considerable time to process.
> 
> Paolo
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html