[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <8BD8E2E5-5F9A-4FD5-9EA1-9EF09073DD56@oracle.com>
Date: Sat, 17 Nov 2018 00:59:39 +0200
From: Liran Alon <liran.alon@...cle.com>
To: syzbot <syzbot+cfbc368e283d381f8cef@...kaller.appspotmail.com>
Cc: bp@...en8.de, hpa@...or.com, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org, mingo@...hat.com,
pbonzini@...hat.com, rkrcmar@...hat.com,
syzkaller-bugs@...glegroups.com, tglx@...utronix.de, x86@...nel.org
Subject: Re: KMSAN: kernel-infoleak in kvm_arch_vcpu_ioctl
> On 17 Nov 2018, at 0:09, syzbot <syzbot+cfbc368e283d381f8cef@...kaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 006aa39cddee kmsan: don't instrument fixup_bad_iret()
> git tree: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_google_kmsan.git_master&d=DwIBaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=Jk6Q8nNzkQ6LJ6g42qARkg6ryIDGQr-yKXPNGZbpTx0&m=6-j0bZwOIu2D7UVtppvdFzCPoDvVU1l3ExqVO_Po11o&s=qBVZxFprJcGeWFBppSXwwkTrx3u7E8vv78UxFb1N2yM&e=
> console output: https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_x_log.txt-3Fx-3D101dcb0b400000&d=DwIBaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=Jk6Q8nNzkQ6LJ6g42qARkg6ryIDGQr-yKXPNGZbpTx0&m=6-j0bZwOIu2D7UVtppvdFzCPoDvVU1l3ExqVO_Po11o&s=m7FuREmXFg2ZHCkPmLKPCIrMU2Pw0zlAPdkpQXTtmHs&e=
> kernel config: https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_x_.config-3Fx-3Df388ea1732f3c473&d=DwIBaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=Jk6Q8nNzkQ6LJ6g42qARkg6ryIDGQr-yKXPNGZbpTx0&m=6-j0bZwOIu2D7UVtppvdFzCPoDvVU1l3ExqVO_Po11o&s=vvmEqhqn8-cl-D88zy6BsN9exSDvIKxVRopXWs0hIYE&e=
> dashboard link: https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_bug-3Fextid-3Dcfbc368e283d381f8cef&d=DwIBaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=Jk6Q8nNzkQ6LJ6g42qARkg6ryIDGQr-yKXPNGZbpTx0&m=6-j0bZwOIu2D7UVtppvdFzCPoDvVU1l3ExqVO_Po11o&s=HTwepMOiTfeo-sYvcbfkdwY3-DouLgzz3XT6a26qLhM&e=
> compiler: clang version 8.0.0 (trunk 343298)
> syz repro: https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_x_repro.syz-3Fx-3D10c56fbd400000&d=DwIBaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=Jk6Q8nNzkQ6LJ6g42qARkg6ryIDGQr-yKXPNGZbpTx0&m=6-j0bZwOIu2D7UVtppvdFzCPoDvVU1l3ExqVO_Po11o&s=N7ZWdZk1M360lcHmoXIX8utlbcjYLe7MPu_Gxe3sLBU&e=
> C reproducer: https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_x_repro.c-3Fx-3D153c8a47400000&d=DwIBaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=Jk6Q8nNzkQ6LJ6g42qARkg6ryIDGQr-yKXPNGZbpTx0&m=6-j0bZwOIu2D7UVtppvdFzCPoDvVU1l3ExqVO_Po11o&s=Y_PwncNZIx_yxjGLefhRu5GpOYmjCqOloLFHGxsH7eQ&e=
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+cfbc368e283d381f8cef@...kaller.appspotmail.com
>
> IPVS: ftp: loaded support on port[0] = 21
> L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3646 and https://urldefense.proofpoint.com/v2/url?u=https-3A__www.kernel.org_doc_html_latest_admin-2Dguide_l1tf.html&d=DwIBaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=Jk6Q8nNzkQ6LJ6g42qARkg6ryIDGQr-yKXPNGZbpTx0&m=6-j0bZwOIu2D7UVtppvdFzCPoDvVU1l3ExqVO_Po11o&s=W59LMRxHTTYAxlGlzLxWOuioL5Z6ousHYqJPO5KJuDI&e= for details.
> ==================================================================
> BUG: KMSAN: kernel-infoleak in _copy_to_user+0x19a/0x230 lib/usercopy.c:31
> CPU: 0 PID: 6697 Comm: syz-executor853 Not tainted 4.20.0-rc2+ #85
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x32d/0x480 lib/dump_stack.c:113
> kmsan_report+0x19f/0x300 mm/kmsan/kmsan.c:911
> kmsan_internal_check_memory+0x35b/0x3b0 mm/kmsan/kmsan.c:993
> kmsan_copy_to_user+0x7c/0xe0 mm/kmsan/kmsan_hooks.c:552
> _copy_to_user+0x19a/0x230 lib/usercopy.c:31
> copy_to_user include/linux/uaccess.h:183 [inline]
> kvm_vcpu_ioctl_enable_cap arch/x86/kvm/x86.c:3834 [inline]
> kvm_arch_vcpu_ioctl+0x5dee/0x7680 arch/x86/kvm/x86.c:4132
> kvm_vcpu_ioctl+0xca3/0x1f90 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2748
> do_vfs_ioctl+0xfbc/0x2f70 fs/ioctl.c:46
> ksys_ioctl fs/ioctl.c:713 [inline]
> __do_sys_ioctl fs/ioctl.c:720 [inline]
> __se_sys_ioctl+0x1da/0x270 fs/ioctl.c:718
> __x64_sys_ioctl+0x4a/0x70 fs/ioctl.c:718
> do_syscall_64+0xcf/0x110 arch/x86/entry/common.c:291
> entry_SYSCALL_64_after_hwframe+0x63/0xe7
> RIP: 0033:0x4471b9
> Code: e8 fc b9 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 3b 07 fc ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007f1e22946da8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 00000000006f0038 RCX: 00000000004471b9
> RDX: 0000000020000000 RSI: 000000004068aea3 RDI: 0000000000000005
> RBP: 00000000006f0030 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 00000000006f003c
> R13: 6d766b2f7665642f R14: 00007f1e229479c0 R15: 00000000000003e8
>
> Local variable description: ----__pu_val@..._arch_vcpu_ioctl
> Variable was created at:
> kvm_arch_vcpu_ioctl+0x29d/0x7680 arch/x86/kvm/x86.c:3848
> kvm_vcpu_ioctl+0xca3/0x1f90 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2748
>
> Bytes 0-1 of 2 are uninitialized
> Memory access of size 2 starts at ffff8881967ffbb0
> Data copied to user address 0000000000706000
> ==================================================================
>
The info-leak bug is very simple, What happens is the following:
1) kvm_vcpu_ioctl_enable_cap() is called to enable KVM_CAP_HYPERV_ENLIGHTENED_VMCS which calls nested_enable_evmcs().
2) nested_enable_evmcs() sets enlightened_vmcs_enabled = true and fills up vmcs_version.
3) kvm_vcpu_ioctl_enable_cap() is called again to enable KVM_CAP_HYPERV_ENLIGHTENED_VMCS which calls nested_enable_evmcs().
4) This time nested_enable_evmcs() just returns 0 as enlightened_vmcs_enabled is already true. Without filling vmcs_version!
5) kvm_vcpu_ioctl_enable_cap() continues as usual and returns uninitialised vmcs_version to userspace which leads to kernel info-leak.
I will create a patch to fix this by changing nested_enable_evmcs() to always fill up vmcs_version field.
-Liran
Powered by blists - more mailing lists