| 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
| ||
|
Message-Id: <059CB3BB-FF3C-46D6-B5ED-E7C50B010E92@gmail.com>
Date: Fri, 15 Jan 2016 10:49:46 -0800
From: Nadav Amit <nadav.amit@...il.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: Dmitry Vyukov <dvyukov@...gle.com>, Gleb Natapov <gleb@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
"x86@...nel.org" <x86@...nel.org>, kvm@...r.kernel.org,
LKML <linux-kernel@...r.kernel.org>, mtosatti@...hat.com,
yoshikawa_takuya_b1@....ntt.co.jp, guangrong.xiao@...ux.intel.com,
syzkaller <syzkaller@...glegroups.com>,
Kostya Serebryany <kcc@...gle.com>,
Alexander Potapenko <glider@...gle.com>,
Eric Dumazet <edumazet@...gle.com>,
Sasha Levin <sasha.levin@...cle.com>
Subject: Re: kvm: WARNING in exception_type
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@...hat.com> wrote:
>
>
> On 15/01/2016 18:11, Dmitry Vyukov wrote:
>> 2016-01-08 16:42 GMT+01:00 Dmitry Vyukov <dvyukov@...gle.com>:
>>> 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@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists