[PATCH] RISC-V: KVM: Fix TOCTOU race in SBI system suspend handler

Andrew Jones andrew.jones at oss.qualcomm.com
Fri May 22 06:12:55 PDT 2026


On Fri, May 22, 2026 at 07:50:43AM -0500, Andrew Jones wrote:
> On Fri, May 22, 2026 at 03:18:13AM +0000, Jiakai Xu wrote:
> > Hi, drew!
> > 
> > Thanks for your review!
> > 
> > > > I'm not a big fan of this approach and I see sashiko found it has gaps[1].
> > 
> > I read sashiko's feedback and I think it makes sense.
> > 
> > > > I'd rather we introduce a mutex to kvm_arch to serialize cross-vcpu
> > > 
> > > Eh, not sure why I said 'introduce' here. We can just use kvm->lock.
> > 
> > I looked into that, but it may be not suitable. Here's why:
> > 
> > Documentation/virt/kvm/locking.rst explicitly states: kvm->lock is taken 
> > outside vcpu->mutex. The susp handler runs inside kvm_arch_vcpu_ioctl_run(), 
> > which is called from kvm_vcpu_ioctl() where vcpu->mutex is already held.
> > 
> > Taking kvm->lock inside the susp handler would produce: vcpu->mutex → kvm->lock.
> > So may be we should introduce a mutex to kvm_arch to serialize cross-vcpu
> > mp-state operations.
> > 
> > What do you think?
> 
> Good catch. I should have trusted my initial instincts to introduce a new
> mutex :-)
>

But... before we get too carried away. Unless I'm missing something, this
race really looks too theoretical to justify any change at all. Do you
have a test case in mind that could force it?

Thanks,
drew



More information about the linux-riscv mailing list