In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Acquire kvm->srcu when handling KVMSETVCPUEVENTS Grab kvm->srcu when processing KVMSETVCPUEVENTS, as KVM will forcibly leave nested VMX/SVM if SMM mode is being toggled, and leaving nested VMX reads guest memory. Note, kvmvcpuioctlx86setvcpuevents() can also be called from KVMRUN via syncregs(), which already holds SRCU. I.e. trying to precisely use kvmvcpusrcureadlock() around the problematic SMM code would cause problems. Acquiring SRCU isn't all that expensive, so for simplicity, grab it unconditionally for KVMSETVCPUEVENTS. ============================= WARNING: suspicious RCU usage 6.10.0-rc7-332d2c1d713e-next-vm #552 Not tainted ----------------------------- include/linux/kvmhost.h:1027 suspicious rcudereferencecheck() usage! other info that might help us debug this: rcuscheduleractive = 2, debuglocks = 1 1 lock held by repro/1071: #0: ffff88811e424430 (&vcpu->mutex){+.+.}-{3:3}, at: kvmvcpuioctl+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> dumpstacklvl+0x7f/0x90 lockdeprcususpicious+0x13f/0x1a0 kvmvcpugfntomemslot+0x168/0x190 [kvm] kvmvcpureadguest+0x3e/0x90 [kvm] nestedvmxloadmsr+0x6b/0x1d0 [kvmintel] loadvmcs12hoststate+0x432/0xb40 [kvmintel] vmxleavenested+0x30/0x40 [kvmintel] kvmvcpuioctlx86setvcpuevents+0x15d/0x2b0 [kvm] kvmarchvcpuioctl+0x1107/0x1750 [kvm] ? markheldlocks+0x49/0x70 ? kvmvcpuioctl+0x7d/0x970 [kvm] ? kvmvcpuioctl+0x497/0x970 [kvm] kvmvcpuioctl+0x497/0x970 [kvm] ? lockacquire+0xba/0x2d0 ? findheldlock+0x2b/0x80 ? douseraddrfault+0x40c/0x6f0 ? lockrelease+0xb7/0x270 _x64sysioctl+0x82/0xb0 dosyscall64+0x6c/0x170 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x7ff11eb1b539 </TASK>