In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Acquire kvm->srcu when handling KVMSETVCPU_EVENTS
Grab kvm->srcu when processing KVMSETVCPU_EVENTS, 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 KVMSETVCPU_EVENTS.
============================= WARNING: suspicious RCU usage 6.10.0-rc7-332d2c1d713e-next-vm #552 Not tainted
include/linux/kvmhost.h:1027 suspicious rcudereference_check() 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: kvmvcpu_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> 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 entrySYSCALL64after_hwframe+0x4b/0x53 RIP: 0033:0x7ff11eb1b539 </TASK>