On Wed, Jan 09, 2019 at 12:35:11PM +0100, Christoffer Dall wrote: > Commit fb544d1ca65a89f7a3895f7531221ceeed74ada7 upstream. > > We recently addressed a VMID generation race by introducing a read/write > lock around accesses and updates to the vmid generation values. > > However, kvm_arch_vcpu_ioctl_run() also calls need_new_vmid_gen() but > does so without taking the read lock. > > As far as I can tell, this can lead to the same kind of race: > > VM 0, VCPU 0 VM 0, VCPU 1 > ------------ ------------ > update_vttbr (vmid 254) > update_vttbr (vmid 1) // roll over > read_lock(kvm_vmid_lock); > force_vm_exit() > local_irq_disable > need_new_vmid_gen == false //because vmid gen matches > > enter_guest (vmid 254) > kvm_arch.vttbr = <PGD>:<VMID 1> > read_unlock(kvm_vmid_lock); > > enter_guest (vmid 1) > > Which results in running two VCPUs in the same VM with different VMIDs > and (even worse) other VCPUs from other VMs could now allocate clashing > VMID 254 from the new generation as long as VCPU 0 is not exiting. > > Attempt to solve this by making sure vttbr is updated before another CPU > can observe the updated VMID generation. > > Change-Id: I40aae6e89a3c8a496e13fcd8ae6bb663d16b057c > Cc: stable@xxxxxxxxxxxxxxx # v4.19 > Fixes: f0cf47d939d0 "KVM: arm/arm64: Close VMID generation race" > Reviewed-by: Julien Thierry <julien.thierry@xxxxxxx> > Signed-off-by: Christoffer Dall <christoffer.dall@xxxxxxx> > Signed-off-by: Marc Zyngier <marc.zyngier@xxxxxxx> > --- > virt/kvm/arm/arm.c | 23 +++++++++++------------ > 1 file changed, 11 insertions(+), 12 deletions(-) Both patches now queued up, thanks. greg k-h
