Re: [syzbot] [kvm?] WARNING in kvm_arch_vcpu_ioctl_run (5)

Sean Christopherson
2023-06-12T23:53:00Z

On Mon, Jun 12, 2023, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 64569520920a Merge tag 'block-6.4-2023-06-09' of git://git..
> git tree: upstream
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=12386cd9280000
> kernel config: https://syzkaller.appspot.com/x/.config?x=3c980bfe8b399968
> dashboard link: https://syzkaller.appspot.com/bug?extid=5feef0b9ee9c8e9e5689
> compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13adcb43280000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13af3853280000
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/4421ae3b4ee0/disk-64569520.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/9312cbb35f54/vmlinux-64569520.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/3476854febf3/bzImage-64569520.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+5feef0b9ee9c8e9e5689@syzkaller.appspotmail.com
>
> kvm_intel: L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html for details.
> kvm: vcpu 1: requested 128 ns lapic timer period limited to 200000 ns
> kvm: vcpu 1: requested lapic timer restore with starting count register 0x390=1812281087 (231971979136 ns) > initial count (200000 ns). Using initial count to start timer.
> ------------[ cut here ]------------
> WARNING: CPU: 1 PID: 5004 at arch/x86/kvm/x86.c:11099 kvm_arch_vcpu_ioctl_run+0x2379/0x2820 arch/x86/kvm/x86.c:11099
> Modules linked in:
> CPU: 1 PID: 5004 Comm: syz-executor120 Not tainted 6.4.0-rc5-syzkaller-00245-g64569520920a #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023
> RIP: 0010:kvm_arch_vcpu_ioctl_run+0x2379/0x2820 arch/x86/kvm/x86.c:11099

KVM doesn't reject KVM_SET_SREGS with a bad CR0, which combined with an L2 that's
configured with unrestricted guest *disabled*, coerces KVM into stuffing VM86 state
to virtualize Real Mode, and eventually leads to all kinds of weirdness. Will post
a patch "shortly" (probably tomorrow at this point).