[PATCH 5.15.y] KVM: x86: Acquire kvm->srcu when handling KVM_SET_VCPU_EVENTS

[PATCH 5.15.y] KVM: x86: Acquire kvm->srcu when handling KVM_SET_VCPU_EVENTS

[Rajani Kantha]

From: Sean Christopherson <seanjc@google.com>

commit 4bcdd831d9d01e0fb64faea50732b59b2ee88da1 upstream.

Grab kvm->srcu when processing KVM_SET_VCPU_EVENTS, as KVM will forcibly
leave nested VMX/SVM if SMM mode is being toggled, and leaving nested VMX
reads guest memory.

Note, kvm_vcpu_ioctl_x86_set_vcpu_events() can also be called from KVM_RUN
via sync_regs(), which already holds SRCU.  I.e. trying to precisely use
kvm_vcpu_srcu_read_lock() around the problematic SMM code would cause
problems.  Acquiring SRCU isn't all that expensive, so for simplicity,
grab it unconditionally for KVM_SET_VCPU_EVENTS.

 =============================
 WARNING: suspicious RCU usage
 6.10.0-rc7-332d2c1d713e-next-vm #552 Not tainted
 -----------------------------
 include/linux/kvm_host.h:1027 suspicious rcu_dereference_check() usage!

 other info that might help us debug this:

 rcu_scheduler_active = 2, debug_locks = 1
 1 lock held by repro/1071:
  #0: ffff88811e424430 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x7d/0x970 [kvm]

 stack backtrace:
 CPU: 15 PID: 1071 Comm: repro Not tainted 6.10.0-rc7-332d2c1d713e-next-vm #552
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
 Call Trace:
  <TASK>
  dump_stack_lvl+0x7f/0x90
  lockdep_rcu_suspicious+0x13f/0x1a0
  kvm_vcpu_gfn_to_memslot+0x168/0x190 [kvm]
  kvm_vcpu_read_guest+0x3e/0x90 [kvm]
  nested_vmx_load_msr+0x6b/0x1d0 [kvm_intel]
  load_vmcs12_host_state+0x432/0xb40 [kvm_intel]
  vmx_leave_nested+0x30/0x40 [kvm_intel]
  kvm_vcpu_ioctl_x86_set_vcpu_events+0x15d/0x2b0 [kvm]
  kvm_arch_vcpu_ioctl+0x1107/0x1750 [kvm]
  ? mark_held_locks+0x49/0x70
  ? kvm_vcpu_ioctl+0x7d/0x970 [kvm]
  ? kvm_vcpu_ioctl+0x497/0x970 [kvm]
  kvm_vcpu_ioctl+0x497/0x970 [kvm]
  ? lock_acquire+0xba/0x2d0
  ? find_held_lock+0x2b/0x80
  ? do_user_addr_fault+0x40c/0x6f0
  ? lock_release+0xb7/0x270
  __x64_sys_ioctl+0x82/0xb0
  do_syscall_64+0x6c/0x170
  entry_SYSCALL_64_after_hwframe+0x4b/0x53
 RIP: 0033:0x7ff11eb1b539
  </TASK>

Fixes: f7e570780efc ("KVM: x86: Forcibly leave nested virt when SMM state is toggled")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20240723232055.3643811-1-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
[ Based on kernel 5.15 available functions, using srcu_read_lock/srcu_read_unlock instead of
kvm_vcpu_srcu_read_lock/kvm_vcpu_srcu_read_unlock ]
Signed-off-by: Rajani Kantha <681739313@139.com>
---
 arch/x86/kvm/x86.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 648f80f73e66..785cd9b4283a 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5294,7 +5294,9 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
 		if (copy_from_user(&events, argp, sizeof(struct kvm_vcpu_events)))
 			break;
 
+		vcpu->srcu_idx = srcu_read_lock(&vcpu->kvm->srcu);
 		r = kvm_vcpu_ioctl_x86_set_vcpu_events(vcpu, &events);
+		srcu_read_unlock(&vcpu->kvm->srcu, vcpu->srcu_idx);
 		break;
 	}
 	case KVM_GET_DEBUGREGS: {
-- 
2.17.1

Re: [PATCH 5.15.y] KVM: x86: Acquire kvm->srcu when handling KVM_SET_VCPU_EVENTS

[Sean Christopherson]

On Thu, Dec 04, 2025, Rajani Kantha wrote:
> From: Sean Christopherson <seanjc@google.com>
> 
> commit 4bcdd831d9d01e0fb64faea50732b59b2ee88da1 upstream.
> 
> Grab kvm->srcu when processing KVM_SET_VCPU_EVENTS, as KVM will forcibly
> leave nested VMX/SVM if SMM mode is being toggled, and leaving nested VMX
> reads guest memory.
> 
> Note, kvm_vcpu_ioctl_x86_set_vcpu_events() can also be called from KVM_RUN
> via sync_regs(), which already holds SRCU.  I.e. trying to precisely use
> kvm_vcpu_srcu_read_lock() around the problematic SMM code would cause
> problems.  Acquiring SRCU isn't all that expensive, so for simplicity,
> grab it unconditionally for KVM_SET_VCPU_EVENTS.
> 
>  =============================
>  WARNING: suspicious RCU usage
>  6.10.0-rc7-332d2c1d713e-next-vm #552 Not tainted
>  -----------------------------
>  include/linux/kvm_host.h:1027 suspicious rcu_dereference_check() usage!
> 
>  other info that might help us debug this:
> 
>  rcu_scheduler_active = 2, debug_locks = 1
>  1 lock held by repro/1071:
>   #0: ffff88811e424430 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x7d/0x970 [kvm]
> 
>  stack backtrace:
>  CPU: 15 PID: 1071 Comm: repro Not tainted 6.10.0-rc7-332d2c1d713e-next-vm #552
>  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
>  Call Trace:
>   <TASK>
>   dump_stack_lvl+0x7f/0x90
>   lockdep_rcu_suspicious+0x13f/0x1a0
>   kvm_vcpu_gfn_to_memslot+0x168/0x190 [kvm]
>   kvm_vcpu_read_guest+0x3e/0x90 [kvm]
>   nested_vmx_load_msr+0x6b/0x1d0 [kvm_intel]
>   load_vmcs12_host_state+0x432/0xb40 [kvm_intel]
>   vmx_leave_nested+0x30/0x40 [kvm_intel]
>   kvm_vcpu_ioctl_x86_set_vcpu_events+0x15d/0x2b0 [kvm]
>   kvm_arch_vcpu_ioctl+0x1107/0x1750 [kvm]
>   ? mark_held_locks+0x49/0x70
>   ? kvm_vcpu_ioctl+0x7d/0x970 [kvm]
>   ? kvm_vcpu_ioctl+0x497/0x970 [kvm]
>   kvm_vcpu_ioctl+0x497/0x970 [kvm]
>   ? lock_acquire+0xba/0x2d0
>   ? find_held_lock+0x2b/0x80
>   ? do_user_addr_fault+0x40c/0x6f0
>   ? lock_release+0xb7/0x270
>   __x64_sys_ioctl+0x82/0xb0
>   do_syscall_64+0x6c/0x170
>   entry_SYSCALL_64_after_hwframe+0x4b/0x53
>  RIP: 0033:0x7ff11eb1b539
>   </TASK>
> 
> Fixes: f7e570780efc ("KVM: x86: Forcibly leave nested virt when SMM state is toggled")
> Cc: stable@vger.kernel.org
> Link: https://lore.kernel.org/r/20240723232055.3643811-1-seanjc@google.com
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> [ Based on kernel 5.15 available functions, using srcu_read_lock/srcu_read_unlock instead of
> kvm_vcpu_srcu_read_lock/kvm_vcpu_srcu_read_unlock ]
> Signed-off-by: Rajani Kantha <681739313@139.com>
> ---

Acked-by: Sean Christopherson <seanjc@google.com>