From: sashiko-bot@kernel.org
To: "Sean Christopherson" <seanjc@google.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v2 4/4] KVM: x86/mmu: Add sanity check to detect stale page faults in "map private PFN"
Date: Wed, 26 Aug 2026 16:55:27 +0000 [thread overview]
Message-ID: <20260826165527.EABCE1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260826164214.756512-5-seanjc@google.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Snapshotting `mmu_invalidate_seq` after acquiring `mmu_lock` and after PFN resolution violates the mandatory MMU retry protocol sequence, bypassing generation-safety checks against concurrent invalidations.
--
commit 3d8d7ec872ba8330e37f8fdcf1804dda38c1cf1e
Author: Sean Christopherson <seanjc@google.com>
KVM: x86/mmu: Add sanity check to detect stale page faults in "map private PFN"
This commit adds a check for stale page faults prior to mapping a private PFN
into the guest. It intentionally snapshots the invalidation sequence after
acquiring the MMU lock to avoid false positives.
> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index 19a501029f089..79c450d677b40 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
> @@ -5236,6 +5236,18 @@ int kvm_tdp_mmu_map_private_pfn(struct kvm_vcpu *vcpu, gfn_t gfn, kvm_pfn_t pfn)
> */
> WARN_ON_ONCE(kvm_test_request(KVM_REQ_MMU_FREE_OBSOLETE_ROOTS, vcpu));
>
> + /*
> + * Snapshot the invalidation sequence counter after acquiring
> + * mmu_lock, as guest_memfd guarantees the validity of the pfn,
> + * i.e. any concurrent invalidations are guaranteed to be
> + * irrelevant.
> + */
> + fault.mmu_seq = vcpu->kvm->mmu_invalidate_seq;
> + if (is_page_fault_stale(vcpu, &fault)) {
[Severity: High]
Does capturing mmu_invalidate_seq after acquiring mmu_lock and after PFN
resolution bypass the mandatory MMU retry protocol safety checks?
According to the KVM memory management guidelines, the invalidation sequence
should be captured before resolving the PFN, and the lock must be acquired
afterward. By snapshotting the sequence here and immediately checking it
via is_page_fault_stale(), the check effectively compares the counter to
itself, which guarantees it will pass.
Could this bypass allow the installation of stale translations or cause a
use-after-free if the caller's guarantees ever fail in the future?
> + r = RET_PF_RETRY;
> + continue;
> + }
> +
> r = kvm_tdp_mmu_map(vcpu, &fault);
> } while (r == RET_PF_RETRY);
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260826164214.756512-1-seanjc@google.com?part=4
prev parent reply other threads:[~2026-08-26 16:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-26 16:42 [PATCH v2 0/4] KVM: x86/mmu: Fix pre-fault and map private loops Sean Christopherson
2026-08-26 16:42 ` [PATCH v2 1/4] KVM: x86/mmu: Reload MMU on *every* page pre-fault attempt/iteration Sean Christopherson
2026-08-26 16:42 ` [PATCH v2 2/4] KVM: x86/mmu: Harden "map private PFN" against unexpected root invalidation Sean Christopherson
2026-08-26 16:59 ` sashiko-bot
2026-08-26 17:08 ` Sean Christopherson
2026-08-26 16:42 ` [PATCH v2 3/4] KVM: x86/mmu: Top-up memory caches when retrying "map private PFN" Sean Christopherson
2026-08-26 16:42 ` [PATCH v2 4/4] KVM: x86/mmu: Add sanity check to detect stale page faults in " Sean Christopherson
2026-08-26 16:55 ` sashiko-bot [this message]
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=20260826165527.EABCE1F000E9@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox