On Thu, Oct 1, 2026 at 1:24 PM Sean Christopherson <[email protected]> wrote: > > Reject user accesses to guest memory, which are supposed to be done only > in the context of KVM_RUN or similar operations, if the current address > space is not the VM's (host userspace) address space. If KVM writes to > guest memory after the owning host process has exited, or if the VM is > being destroyed in the context of a different process, then writing using > the wrong address space will corrupt a different process' memory. > > Reject the access but don't WARN() or KVM_BUG_ON() event though attempting > to access guest memory with a mismatched address space is a blatant KVM > bug, because unfortunately KVM is buggy. On KVM VMX, when a vCPU is > destroyed while L2 is active, KVM synthesizes a nested VM-Exit to force the > vCPU out of L2 in order to free the nested VMX assets, and a side effect of > a nested VM-Exit is that it flushes the cached shadow VMCS12 back to guest > memory: > > vmx_vcpu_free() > |-> nested_vmx_free_vcpu() > |-> vmx_leave_nested() > |-> nested_vmx_vmexit(vcpu, -1, 0, 0) > |-> nested_flush_cached_shadow_vmcs12() > |-> kvm_write_guest_cached() > |-> __copy_to_user(ghc->hva, ...) > > Fix the bug broadly even though the "real" bug is that KVM abuses the > nested VM-Exit flow for non-architectural purposes, as there may be other > such violations lurking. For now, punt on fixing individual bugs and > hardening the common flows, e.g. with WARNs. > > Opportunistically provide wrappers in anticipation of adding more checks > and hardening, i.e. growing the logic beyond checking current->mm. > > Fixes: 61ada7488ffd ("KVM: nVMX: Cache shadow vmcs12 on VMEntry and flush to > memory on VMExit") > Cc: [email protected] > Reported-by: Jim Mattson <[email protected]> > Closes: > https://lore.kernel.org/all/[email protected] > Signed-off-by: Sean Christopherson <[email protected]>
Thanks, Sean. Feel free to add: Reviewed-by: James Houghton <[email protected]> I wonder if it makes sense to add similar hardening to kvm_faultin_pfn(). What do you think?
