Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Paolo Bonzini" <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH 5.15.y v2 4/8] KVM: x86/mmu: Always pass 0 for @quadrant when gptes are 8 bytes
Date: Fri, 26 Jun 2026 17:58:03 +0000	[thread overview]
Message-ID: <20260626175803.D20C41F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260626174620.1819772-5-pbonzini@redhat.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The patch introduces a guest-triggerable WARN_ON_ONCE in mmu_alloc_root(), which causes a host denial of service (DoS) when panic_on_warn is enabled.
--

commit 8c0238e94cdb540684953deca3c7dac664d9db92
Author: Paolo Bonzini <pbonzini@redhat.com>

KVM: x86/mmu: Always pass 0 for @quadrant when gptes are 8 bytes

This commit simplifies quadrant passing for PAE page directories by only
passing a non-zero quadrant when actually necessary. It also adds sanity
warnings to enforce these invariants.

> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index 3a5ed96703776..dbc18d4cc572c 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
> @@ -3444,9 +3444,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]
Does this new assertion assume that direct-mapped roots only occur with TDP?

When a guest runs with paging disabled (CR0.PG=0) on a host using the shadow
MMU, KVM operates the shadow MMU in a direct-mapped configuration. In this
context, kvm_calc_shadow_mmu_root_page_role() sets role.base.direct = 1 and
role.base.gpte_is_8_bytes = 0.

When KVM loads the MMU context, it invokes mmu_alloc_direct_roots(), which
subsequently calls mmu_alloc_root(). Under these conditions, the new
assertion evaluates to true and triggers unconditionally.

Since this path is reachable during a normal guest boot sequence, or
maliciously by a guest repeatedly disabling paging, could a guest use this to
trigger host warnings or kernel panics when panic_on_warn is enabled?

>  
>  	sp = kvm_mmu_get_page(vcpu, gfn, role);
>  	++sp->root_count;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260626174620.1819772-1-pbonzini@redhat.com?part=4

  reply	other threads:[~2026-06-26 17:58 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-26 17:46 [PATCH 5.15.y v2 0/8] KVM: fixes for CVE-2026-46113 and related issues Paolo Bonzini
2026-06-26 17:46 ` [PATCH 5.15.y v2 1/8] KVM: x86/mmu: Use a bool for direct Paolo Bonzini
2026-06-26 17:46 ` [PATCH 5.15.y v2 2/8] KVM: x86/mmu: Stop passing "direct" to mmu_alloc_root() Paolo Bonzini
2026-06-26 17:46 ` [PATCH 5.15.y v2 3/8] KVM: x86/mmu: Derive shadow MMU page role from parent Paolo Bonzini
2026-06-26 18:07   ` sashiko-bot
2026-06-26 17:46 ` [PATCH 5.15.y v2 4/8] KVM: x86/mmu: Always pass 0 for @quadrant when gptes are 8 bytes Paolo Bonzini
2026-06-26 17:58   ` sashiko-bot [this message]
2026-06-26 17:46 ` [PATCH 5.15.y v2 5/8] KVM: x86/mmu: pull call to drop_large_spte() into __link_shadow_page() Paolo Bonzini
2026-06-26 17:59   ` sashiko-bot
2026-06-26 17:46 ` [PATCH 5.15.y v2 6/8] KVM: x86: Fix shadow paging use-after-free due to unexpected GFN Paolo Bonzini
2026-06-26 17:46 ` [PATCH 5.15.y v2 7/8] KVM: x86: Fix shadow paging use-after-free due to unexpected role Paolo Bonzini
2026-06-26 17:46 ` [PATCH 5.15.y v2 8/8] KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level Paolo Bonzini
2026-06-27 16:35 ` [PATCH 5.15.y v2 0/8] KVM: fixes for CVE-2026-46113 and related issues Sasha Levin
2026-07-10  5:52   ` Kenta Akagi
2026-07-10 21:24     ` Sasha Levin

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=20260626175803.D20C41F000E9@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