[syzbot ci] Re: KVM: x86: Unconditionally recompute CR8 intercept on PPR update

[syzbot ci]

syzbot ci has tested the following series

[v2] KVM: x86: Unconditionally recompute CR8 intercept on PPR update
https://lore.kernel.org/all/20260610214523....@suse.de
* [PATCH v2] KVM: x86: Unconditionally recompute CR8 intercept on PPR update

and found the following issue:
WARNING in vmx_update_cr8_intercept

Full report is available here:
https://ci.syzbot.org/series/d94aebb2-8082-4777-ab08-5c3a0d680bed

***

WARNING in vmx_update_cr8_intercept

tree: linux-next
URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next
base: c1f7303302927f9cbf4efedf70f0512cde168c65
arch: amd64
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config: https://ci.syzbot.org/builds/8f417377-50a6-450a-8ce0-a83de33b8c6d/config
syz repro: https://ci.syzbot.org/findings/62a660e6-a9b1-42ca-9cf0-7aadd2f5d292/syz_repro

------------[ cut here ]------------
debug_locks && !(lock_is_held(&(&vcpu->mutex)->dep_map) || !refcount_read(&vcpu->kvm->users_count))
WARNING: arch/x86/kvm/vmx/nested.h:61 at get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline], CPU#0: syz.2.19/5879
WARNING: arch/x86/kvm/vmx/nested.h:61 at vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879, CPU#0: syz.2.19/5879
Modules linked in:
CPU: 0 UID: 0 PID: 5879 Comm: syz.2.19 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
RIP: 0010:get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline]
RIP: 0010:vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879
Code: 0b 90 e9 f1 fe ff ff e8 30 12 69 00 90 0f 0b 90 e9 59 fe ff ff e8 22 12 69 00 e8 ad 86 d6 ff e9 ca fe ff ff e8 13 12 69 00 90 <0f> 0b 90 e9 fc fc ff ff e8 05 12 69 00 e8 90 86 d6 ff eb a7 48 c7
RSP: 0018:ffffc9000271f758 EFLAGS: 00010293
RAX: ffffffff815d048d RBX: ffff888113380000 RCX: ffff8881142b8000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
RBP: 00000000ffffffff R08: ffff8881114d9703 R09: 1ffff1102229b2e0
R10: dffffc0000000000 R11: ffffed102229b2e1 R12: 0000000000000000
R13: dffffc0000000000 R14: ffff888116d0bca0 R15: 0000000000000001
FS: 00007ff34d6b86c0(0000) GS:ffff88818dc9b000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffc75e78ae8 CR3: 000000010c609000 CR4: 0000000000352ef0
Call Trace:
<TASK>
apic_update_ppr arch/x86/kvm/lapic.c:984 [inline]
kvm_lapic_reset+0x1c24/0x2980 arch/x86/kvm/lapic.c:3023
kvm_vcpu_reset+0x44c/0x1bf0 arch/x86/kvm/x86.c:12986
kvm_arch_vcpu_create+0x746/0x8b0 arch/x86/kvm/x86.c:12847
kvm_vm_ioctl_create_vcpu+0x428/0x930 virt/kvm/kvm_main.c:4201
kvm_vm_ioctl+0x893/0xd50 virt/kvm/kvm_main.c:5159
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+0x174/0x580 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7ff34c79ce59
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 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 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ff34d6b8028 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007ff34ca15fa0 RCX: 00007ff34c79ce59
RDX: 0000000000000002 RSI: 000000000000ae41 RDI: 0000000000000004
RBP: 00007ff34c832d6f R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ff34ca16038 R14: 00007ff34ca15fa0 R15: 00007ffe4bc28aa8
</TASK>


***

If these findings have caused you to resend the series or submit a
separate fix, please add the following tag to your commit message:
Tested-by: syz...@syzkaller.appspotmail.com

---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzk...@googlegroups.com.

To test a patch for this bug, please reply with `#syz test`
(should be on a separate line).

The patch should be attached to the email.
Note: arguments like custom git repos and branches are not supported.

[Sean Christopherson]

On Thu, Jun 11, 2026, syzbot ci wrote:
> syzbot ci has tested the following series
>
> [v2] KVM: x86: Unconditionally recompute CR8 intercept on PPR update
> https://lore.kernel.org/all/20260610214523....@suse.de
> * [PATCH v2] KVM: x86: Unconditionally recompute CR8 intercept on PPR update
>
> and found the following issue:
> WARNING in vmx_update_cr8_intercept

...

> ------------[ cut here ]------------
> debug_locks && !(lock_is_held(&(&vcpu->mutex)->dep_map) || !refcount_read(&vcpu->kvm->users_count))
> WARNING: arch/x86/kvm/vmx/nested.h:61 at get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline], CPU#0: syz.2.19/5879
> WARNING: arch/x86/kvm/vmx/nested.h:61 at vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879, CPU#0: syz.2.19/5879
> Modules linked in:
> CPU: 0 UID: 0 PID: 5879 Comm: syz.2.19 Not tainted syzkaller #0 PREEMPT(full)
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
> RIP: 0010:get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline]
> RIP: 0010:vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879

> apic_update_ppr arch/x86/kvm/lapic.c:984 [inline]
> kvm_lapic_reset+0x1c24/0x2980 arch/x86/kvm/lapic.c:3023
> kvm_vcpu_reset+0x44c/0x1bf0 arch/x86/kvm/x86.c:12986
> kvm_arch_vcpu_create+0x746/0x8b0 arch/x86/kvm/x86.c:12847
> kvm_vm_ioctl_create_vcpu+0x428/0x930 virt/kvm/kvm_main.c:4201
> kvm_vm_ioctl+0x893/0xd50 virt/kvm/kvm_main.c:5159
> 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+0x174/0x580 arch/x86/entry/syscall_64.c:94
> entry_SYSCALL_64_after_hwframe+0x77/0x7f

This is "fine", the assertion just wants to make sure KVM isn't access vmcs12
without holding vcpu->mutex, otherwise any queries are inherently unstable.
It's just that vCPU creation runs without taking vcpu->mutex, because the vCPU
is otherwise unreachable.

I'm pretty sure we can squash the WARN by grabbing vmcs12 if and only if the vCPU
is actually in guest mode.

diff --git arch/x86/kvm/vmx/vmx.c arch/x86/kvm/vmx/vmx.c
index c548f22375ad..332fbcd924f2 100644
--- arch/x86/kvm/vmx/vmx.c
+++ arch/x86/kvm/vmx/vmx.c
@@ -6876,11 +6876,10 @@ int vmx_handle_exit(struct kvm_vcpu *vcpu, fastpath_t exit_fastpath)

void vmx_update_cr8_intercept(struct kvm_vcpu *vcpu, int tpr, int irr)
{
- struct vmcs12 *vmcs12 = get_vmcs12(vcpu);
int tpr_threshold;

if (is_guest_mode(vcpu) &&
- nested_cpu_has(vmcs12, CPU_BASED_TPR_SHADOW))
+ nested_cpu_has(get_vmcs12(vcpu), CPU_BASED_TPR_SHADOW))
return;

guard(vmx_vmcs01)(vcpu);


Longer term, I'll work on figuring out how to handle this in get_vmcs12(), because
to_hv_vcpu() has the solve the same fundamental problem:

https://lore.kernel.org/all/aeqRzanS...@google.com