Re: [syzbot] [kvm-x86?] WARNING in kvm_apic_accept_events

[Sean Christopherson <seanjc@google.com>]

On Thu, Jun 05, 2025, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    64980441d269 Merge tag 'bpf-fixes' of git://git.kernel.org..
> git tree:       upstream
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=145b31d4580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=73696606574e3967
> dashboard link: https://syzkaller.appspot.com/bug?extid=b1784a9a955885da51cd
> compiler:       Debian clang version 20.1.6 (++20250514063057+1e4d39e07757-1~exp1~20250514183223.118), Debian LLD 20.1.6
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=110fcc0c580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16340c0c580000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/b721c3fbaf59/disk-64980441.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/b28b1e530885/vmlinux-64980441.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/5aee07cc8b41/bzImage-64980441.xz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+b1784a9a955885da51cd@syzkaller.appspotmail.com
> 
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 5841 at arch/x86/kvm/lapic.c:3407 kvm_apic_accept_events+0x341/0x490 arch/x86/kvm/lapic.c:3407
> Modules linked in:
> CPU: 0 UID: 0 PID: 5841 Comm: syz-executor279 Not tainted 6.15.0-syzkaller-12058-g64980441d269 #0 PREEMPT(full) 
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
> RIP: 0010:kvm_apic_accept_events+0x341/0x490 arch/x86/kvm/lapic.c:3407

Pretty straightforward; syzkaller sets MP_STATE to INIT_RECEIVED, and then
stuffs vmxon.  KVM, courtesy of commit 28bf28887976 ("KVM: x86: fix user
triggerable warning in kvm_apic_accept_events()"), only guards against the
opposite ordering.

Rather than play a losing game of whack-a-mole with ioctl ordering (SVM's GIF=0
case is even harder to deal with), I'm going to modify KVM to wait until KVM_RUN
to enforce the check, similar to how KVM handles the scenario where emulation is
required (due to !URG) but KVM can't emulate.