All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Sean Christopherson" <seanjc@google.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v2 6/9] KVM: x86/mmu: Split kvm_mmu_zap_all_fast() into "front" and "back" halves
Date: Fri, 26 Jun 2026 23:29:34 +0000	[thread overview]
Message-ID: <20260626232934.D99A11F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260626231416.3943216-7-seanjc@google.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Evaluating `kvm_memslot_flush_zap_all(kvm)` twice in `kvm_arch_flush_shadow_memslot()` creates a TOCTOU race window that allows concurrent quirk modification to skip the back-half zap, leading to a Use-After-Free of host memory.
--

commit daadba9269f9868eb59f2fe4d2fd49715b55bc67
Author: Sean Christopherson <seanjc@google.com>

KVM: x86/mmu: Split kvm_mmu_zap_all_fast() into "front" and "back" halves

This commit splits kvm_mmu_zap_all_fast() into a front half (running with
mmu_lock held for write) and a back half (running outside of mmu_lock).
This allows sharing the mmu_lock critical section when zapping in response
to a memslot being deleted or moved.

Cc: stable@vger.kernel.org # 6.12.x

> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index 223d80b12b9b6..5925db37543f3 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c

[ ... ]

> @@ -7578,14 +7591,19 @@ void kvm_arch_flush_shadow_memslot(struct kvm *kvm,
>  	};
>  	bool flush;
>  
> +	write_lock(&kvm->mmu_lock);
> +
>  	if (kvm_memslot_flush_zap_all(kvm)) {
> -		kvm_mmu_zap_all_fast(kvm);
> +		__kvm_mmu_zap_all_fast_front_half(kvm);
>  	} else {
> -		write_lock(&kvm->mmu_lock);
>  		flush = kvm_unmap_gfn_range(kvm, &range);
>  		kvm_mmu_zap_memslot_pages_and_flush(kvm, slot, flush);
> -		write_unlock(&kvm->mmu_lock);
>  	}
> +
> +	write_unlock(&kvm->mmu_lock);
> +
> +	if (kvm_memslot_flush_zap_all(kvm))
> +		__kvm_mmu_zap_all_fast_back_half(kvm);
>  }

[Severity: Critical]
Can kvm_memslot_flush_zap_all() evaluate differently on the second check in
kvm_arch_flush_shadow_memslot()?

Since kvm_memslot_flush_zap_all() dynamically checks disabled_quirks, if a
concurrent thread disables KVM_X86_QUIRK_SLOT_ZAP_ALL after the front half
executes but before the back half check:

Thread 1 in kvm_arch_flush_shadow_memslot():
    if (kvm_memslot_flush_zap_all(kvm))
        __kvm_mmu_zap_all_fast_front_half(kvm);
        
Thread 2:
    KVM_ENABLE_CAP with KVM_CAP_DISABLE_QUIRKS
    (disables KVM_X86_QUIRK_SLOT_ZAP_ALL)
    
Thread 1 resumes:
    if (kvm_memslot_flush_zap_all(kvm))
        // Evaluates to false, skips back half
        __kvm_mmu_zap_all_fast_back_half(kvm);
        
Could this skip the back half zap and leave invalidated TDP MMU roots
unzapped? If so, this could lead to a use-after-free because KVM's MMU
notifiers will not find the mapping to zap it when the host frees the memory.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260626231416.3943216-1-seanjc@google.com?part=6

  reply	other threads:[~2026-06-26 23:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-26 23:14 [PATCH v2 0/9] KVM: SEV: Fix RMP #PF due freeing in-use VMSA Sean Christopherson
2026-06-26 23:14 ` [PATCH v2 1/9] KVM: SEV: Track the GPA of the guest-controlled VMSA used for SNP guests Sean Christopherson
2026-06-26 23:14 ` [PATCH v2 2/9] KVM: SEV: Extract loading of guest-provided VMSA to a separate helper Sean Christopherson
2026-06-26 23:14 ` [PATCH v2 3/9] KVM: SEV: Mark vCPU RUNNABLE after AP_CREATE, even if VMSA is unusable Sean Christopherson
2026-06-26 23:14 ` [PATCH v2 4/9] KVM: Rework .gmem_invalidate() into .gmem_free_folio() Sean Christopherson
2026-06-29 21:50   ` Ackerley Tng
2026-06-29 22:02     ` Sean Christopherson
2026-06-30  0:09       ` Ackerley Tng
2026-06-30  0:18         ` Sean Christopherson
2026-06-26 23:14 ` [PATCH v2 5/9] KVM: x86/mmu: Fold kvm_mmu_zap_memslot() into kvm_arch_flush_shadow_memslot() Sean Christopherson
2026-06-26 23:14 ` [PATCH v2 6/9] KVM: x86/mmu: Split kvm_mmu_zap_all_fast() into "front" and "back" halves Sean Christopherson
2026-06-26 23:29   ` sashiko-bot [this message]
2026-06-26 23:14 ` [PATCH v2 7/9] KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped Sean Christopherson
2026-06-26 23:39   ` sashiko-bot
2026-06-29 21:59   ` Ackerley Tng
2026-06-29 23:49     ` Sean Christopherson
2026-06-26 23:14 ` [PATCH v2 8/9] KVM: x86: Guard .gmem_prepare() declarations with HAVE_KVM_GMEM_PREPARE=y Sean Christopherson
2026-06-26 23:14 ` [PATCH v2 9/9] KVM: SEV: Mark vCPU has having guest-provided VMSA even if its invalid Sean Christopherson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260626232934.D99A11F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=seanjc@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.