Re: [PATCH v2 01/10] KVM: Reject user accesses to guest memory if current->mm != kvm->mm

On Thu, Oct 01, 2026, James Houghton wrote:

On Thu, Oct 1, 2026 at 1:24 PM Sean Christopherson [off-list ref] wrote:

quoted

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: stable@vger.kernel.org
Reported-by: Jim Mattson <redacted>
Closes: https://lore.kernel.org/all/20260908132838.2116068-1-jmattson@google.com (local)
Signed-off-by: Sean Christopherson <seanjc@google.com>

Thanks, Sean. Feel free to add:

Reviewed-by: James Houghton <redacted>

I wonder if it makes sense to add similar hardening to kvm_faultin_pfn().
What do you think?

I'm not opposed to explicitly hardening kvm_faultin_pfn(), but I don't think it
would add much value in practice.  Far more arch code uses __kvm_faultin_pfn()
directly, and that doesn't have a @vcpu or @vm pointer to do the check.  We could
obviously "fix" that, but nuking the memslots (patches 3-5) will prevent all but
the most ridiculous bugs.  Getting anywhere near __kvm_faultin_pfn() with the
wrong mm would either mean KVM is doing something amazingly stupid during VM
teardown, or I guess maybe the scheduler or preempt notifiers went off the rails?