diff options
author | David Matlack <dmatlack@google.com> | 2023-03-13 16:54:54 -0700 |
---|---|---|
committer | Oliver Upton <oliver.upton@linux.dev> | 2023-03-14 16:47:10 +0000 |
commit | 13ec9308a85702af7c31f3638a2720863848a7f2 (patch) | |
tree | abd03c7eaeb709f85f95636c8e594d1e935f8808 /net/mptcp/token_test.c | |
parent | f6da81f650fa47b61b847488f3938d43f90d093d (diff) |
KVM: arm64: Retry fault if vma_lookup() results become invalid
Read mmu_invalidate_seq before dropping the mmap_lock so that KVM can
detect if the results of vma_lookup() (e.g. vma_shift) become stale
before it acquires kvm->mmu_lock. This fixes a theoretical bug where a
VMA could be changed by userspace after vma_lookup() and before KVM
reads the mmu_invalidate_seq, causing KVM to install page table entries
based on a (possibly) no-longer-valid vma_shift.
Re-order the MMU cache top-up to earlier in user_mem_abort() so that it
is not done after KVM has read mmu_invalidate_seq (i.e. so as to avoid
inducing spurious fault retries).
This bug has existed since KVM/ARM's inception. It's unlikely that any
sane userspace currently modifies VMAs in such a way as to trigger this
race. And even with directed testing I was unable to reproduce it. But a
sufficiently motivated host userspace might be able to exploit this
race.
Fixes: 94f8e6418d39 ("KVM: ARM: Handle guest faults in KVM")
Cc: stable@vger.kernel.org
Reported-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20230313235454.2964067-1-dmatlack@google.com
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Diffstat (limited to 'net/mptcp/token_test.c')
0 files changed, 0 insertions, 0 deletions