aboutsummaryrefslogtreecommitdiff
path: root/net/mptcp/token_test.c
diff options
context:
space:
mode:
authorDavid Matlack <dmatlack@google.com>2023-03-13 16:54:54 -0700
committerOliver Upton <oliver.upton@linux.dev>2023-03-14 16:47:10 +0000
commit13ec9308a85702af7c31f3638a2720863848a7f2 (patch)
treeabd03c7eaeb709f85f95636c8e594d1e935f8808 /net/mptcp/token_test.c
parentf6da81f650fa47b61b847488f3938d43f90d093d (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