Re: [syzbot] [kvm-x86?] WARNING in x86_emulate_insn (2)

Sean Christopherson
2025-11-24T20:20:33Z

On Mon, Nov 24, 2025, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: d724c6f85e80 Add linux-next specific files for 20251121
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=11513612580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=763fb984aa266726
> dashboard link: https://syzkaller.appspot.com/bug?extid=fa52a184ebce1b30ad49
> compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=165638b4580000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15c00e58580000
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/b2f349c65e3c/disk-d724c6f8.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/aba40ae987ce/vmlinux-d724c6f8.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/0b98fbfe576f/bzImage-d724c6f8.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+fa52a184ebce1b30ad49@syzkaller.appspotmail.com
>
> ------------[ cut here ]------------
> WARNING: arch/x86/kvm/emulate.c:5560 at x86_emulate_insn+0x2909/0x41a0 arch/x86/kvm/emulate.c:5560, CPU#1: syz.1.2382/16268
> Modules linked in:
> CPU: 1 UID: 0 PID: 16268 Comm: syz.1.2382 Not tainted syzkaller #0 PREEMPT(full)
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
> RIP: 0010:x86_emulate_insn+0x2909/0x41a0 arch/x86/kvm/emulate.c:5560
> Code: 36 31 ff 44 89 f6 e8 66 99 77 00 45 85 f6 0f 84 05 02 00 00 e8 18 95 77 00 41 bf 01 00 00 00 e9 ef e0 ff ff e8 08 95 77 00 90 <0f> 0b 90 48 8b 44 24 50 42 80 3c 20 00 48 8b 5c 24 48 74 08 48 89
> RSP: 0018:ffffc9000d6ff6c0 EFLAGS: 00010293
> RAX: ffffffff814a8468 RBX: 000304000010220a RCX: ffff88807d930000
> RDX: 0000000000000000 RSI: 00000000000000ff RDI: 000000000000001f
> RBP: ffffc9000d6ff7d0 R08: ffff88807d930000 R09: 0000000000000002
> R10: 0000000000000006 R11: 0000000000000000 R12: dffffc0000000000
> R13: 1ffff92001adfee8 R14: 00000000000000ff R15: ffff888060266780
> FS: 00007f90f1e156c0(0000) GS:ffff888125b6f000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000000 CR3: 00000000745ec000 CR4: 00000000003526f0
> Call Trace:
> <TASK>
> x86_emulate_instruction+0xea7/0x20b0 arch/x86/kvm/x86.c:9521
> kvm_arch_vcpu_ioctl_run+0x1404/0x1cd0 arch/x86/kvm/x86.c:11960
> kvm_vcpu_ioctl+0x99a/0xed0 virt/kvm/kvm_main.c:4477
> vfs_ioctl fs/ioctl.c:51 [inline]
> __do_sys_ioctl fs/ioctl.c:597 [inline]
> __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583
> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7f90f0f8f749
> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007f90f1e15038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 00007f90f11e6090 RCX: 00007f90f0f8f749
> RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005
> RBP: 00007f90f1013f91 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> R13: 00007f90f11e6128 R14: 00007f90f11e6090 R15: 00007ffc7b4d1758
> </TASK>

Given the timing, I assume the just-added AVX emulation support broke something,
but for the life of me I can't repro the splat, and I've spent several hours
going over the code and can't find a smoking gun. Based on the limited stack
trace and context, AFAICT exception.vector is left at '-1' from init_emulate_ctxt(),
and re-emulating an already-decoded INS after a userspace exit triggers the WARN.

The only path I see that has any possibility of generating X86EMUL_PROPAGATE_FAULT
without setting the exception info is if KVM managed to pass gva=-1ull to
nonpaging_gva_to_gpa(), in which case KVM would regurgitate the gva as the gpa,
which would result in a false positive on INVALID_GPA. But nonpaging_gva_to_gpa()
should be unreachable given how the guest is configured.

So, to try rule out the AVX changes, linux-next with the AVX changes reverted:

#syz test: https://github.com/sean-jc/linux.git x86/emulator_no_avx