From: sashiko-bot@kernel.org
To: "Paolo Bonzini" <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH 5.10.y 11/17] KVM: x86/mmu: Always pass 0 for @quadrant when gptes are 8 bytes
Date: Fri, 26 Jun 2026 13:28:22 +0000 [thread overview]
Message-ID: <20260626132823.3432A1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260626112634.1778506-12-pbonzini@redhat.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [High] The newly added `WARN_ON_ONCE(role.direct && !role.gpte_is_8_bytes)` is factually incorrect and trivially triggerable by an unprivileged guest, leading to a host-side Denial of Service if `panic_on_warn` is enabled.
Pre-existing issues:
- [High] In direct MMU mappings for non-paging guests, child shadow page allocation incorrectly applies 32-bit quadrant logic and triggers a warning.
--
commit 890f97eba3156db8c16203bd93e23c5a69ffdd15
Author: Paolo Bonzini <pbonzini@redhat.com>
KVM: x86/mmu: Always pass 0 for @quadrant when gptes are 8 bytes
The quadrant is only used when gptes are 4 bytes, but
mmu_alloc_{direct,shadow}_roots() pass in a non-zero quadrant for PAE
page directories regardless. Make this less confusing by only passing in
a non-zero quadrant when it is actually necessary.
Message-Id: <20220516232138.1783324-6-dmatlack@google.com>
> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index e4759156a2dc8..76d87da1d0712 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
> @@ -3263,9 +3263,10 @@ static hpa_t mmu_alloc_root(struct kvm_vcpu *vcpu, gfn_t gfn, int quadrant,
> struct kvm_mmu_page *sp;
>
> role.level = level;
> + role.quadrant = quadrant;
>
> - if (!role.gpte_is_8_bytes)
> - role.quadrant = quadrant;
> + WARN_ON_ONCE(quadrant && role.gpte_is_8_bytes);
> + WARN_ON_ONCE(role.direct && !role.gpte_is_8_bytes);
[Severity: High]
Can this new warning be triggered by an unprivileged guest?
If a guest runs with TDP disabled (Shadow MMU active) and disables paging
(e.g., boots in real mode), kvm_calc_shadow_mmu_root_page_role() sets
role.base.direct = 1 and role.base.gpte_is_8_bytes = 0.
When mmu_alloc_direct_roots() calls mmu_alloc_root() for a direct MMU
root, won't this unconditionally hit the WARN_ON_ONCE and potentially
cause a host panic if panic_on_warn is enabled?
> sp = kvm_mmu_get_page(vcpu, gfn, role);
> ++sp->root_count;
[ ... ]
[Severity: High]
This isn't a bug introduced by this patch, but a prior patch in the series
appears to have introduced a similar issue for direct MMU mappings for
non-paging guests.
When a guest operates without paging using the Shadow MMU, the root shadow
page has role.direct = 1 and role.gpte_is_8_bytes = 0.
During page faults, __direct_map() allocates intermediate shadow pages by
calling kvm_mmu_get_child_sp() -> kvm_mmu_child_role():
arch/x86/kvm/mmu/mmu.c:kvm_mmu_child_role() {
...
if (!role.gpte_is_8_bytes) {
WARN_ON_ONCE(role.level != PG_LEVEL_4K);
role.quadrant = (sptep - parent_sp->spt) % 2;
}
...
}
Since role.gpte_is_8_bytes == 0, does this erroneously execute the 32-bit
guest PAE-shadowing path, triggering the warning when allocating level 2
shadow pages and incorrectly assigning a quadrant to direct mapping pages?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260626112634.1778506-1-pbonzini@redhat.com?part=11
next prev parent reply other threads:[~2026-06-26 13:28 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-26 11:26 [PATCH 5.10.y 00/17] KVM: fixes for CVE-2026-46113 and related issues Paolo Bonzini
2026-06-26 11:26 ` [PATCH 5.10.y 01/17] KVM: x86/mmu: Capture 'mmu' in a local variable when allocating roots Paolo Bonzini
2026-06-26 11:26 ` [PATCH 5.10.y 02/17] KVM: x86/mmu: Allocate the lm_root before allocating PAE roots Paolo Bonzini
2026-06-26 11:26 ` [PATCH 5.10.y 03/17] KVM: x86/mmu: Allocate pae_root and lm_root pages in dedicated helper Paolo Bonzini
2026-06-26 11:26 ` [PATCH 5.10.y 04/17] KVM: x86/mmu: Ensure MMU pages are available when allocating roots Paolo Bonzini
2026-06-26 12:26 ` sashiko-bot
2026-06-26 17:54 ` Sasha Levin
2026-06-26 11:26 ` [PATCH 5.10.y 05/17] KVM: x86/mmu: Use a bool for direct Paolo Bonzini
2026-06-26 11:26 ` [PATCH 5.10.y 06/17] KVM: x86/mmu: Stop passing "direct" to mmu_alloc_root() Paolo Bonzini
2026-06-26 11:26 ` [PATCH 5.10.y 07/17] KVM: x86/mmu: Refactor shadow walk in __direct_map() to reduce indentation Paolo Bonzini
2026-06-26 11:26 ` [PATCH 5.10.y 08/17] KVM: X86: Fix missed remote tlb flush in rmap_write_protect() Paolo Bonzini
2026-06-26 11:26 ` [PATCH 5.10.y 09/17] KVM: X86: Synchronize the shadow pagetable before link it Paolo Bonzini
2026-06-26 11:26 ` [PATCH 5.10.y 10/17] KVM: x86/mmu: Derive shadow MMU page role from parent Paolo Bonzini
2026-06-26 11:26 ` [PATCH 5.10.y 11/17] KVM: x86/mmu: Always pass 0 for @quadrant when gptes are 8 bytes Paolo Bonzini
2026-06-26 13:28 ` sashiko-bot [this message]
2026-06-26 11:26 ` [PATCH 5.10.y 12/17] KVM: x86/mmu: Check PDPTRs before allocating PAE roots Paolo Bonzini
2026-06-26 13:44 ` sashiko-bot
2026-06-26 11:26 ` [PATCH 5.10.y 13/17] KVM: x86/mmu: pull call to drop_large_spte() into __link_shadow_page() Paolo Bonzini
2026-06-26 14:01 ` sashiko-bot
2026-06-26 11:26 ` [PATCH 5.10.y 14/17] KVM: x86: Fix shadow paging use-after-free due to unexpected GFN Paolo Bonzini
2026-06-26 11:26 ` [PATCH 5.10.y 15/17] KVM: x86: Fix shadow paging use-after-free due to unexpected role Paolo Bonzini
2026-06-26 11:26 ` [PATCH 5.10.y 16/17] KVM: x86/mmu: Pass the memslot to the rmap callbacks Paolo Bonzini
2026-06-26 11:26 ` [PATCH 5.10.y 17/17] KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level Paolo Bonzini
2026-06-26 14:53 ` sashiko-bot
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=20260626132823.3432A1F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=sashiko-reviews@lists.linux.dev \
/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