Linux KVM/arm64 development list
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Vincent Donnefort" <vdonnefort@google.com>
Cc: "Marc Zyngier" <maz@kernel.org>,
	"Oliver Upton" <oupton@kernel.org>,
	kvmarm@lists.linux.dev
Subject: Re: [PATCH v6 11/18] KVM: arm64: Filter out non-kernel addresses in kern_hyp_va
Date: Thu, 01 Oct 2026 15:35:11 +0000	[thread overview]
Message-ID: <20261001153512.46EFA1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20261001142849.3367614-12-vdonnefort@google.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] mm: EL2 memory corruption via kern_hyp_va bypass for non-TTBR1 addresses
--

commit 8768ff7b59b5b3eb8674eb929fc20e711a216dbf
Author: Vincent Donnefort <vdonnefort@google.com>

KVM: arm64: Filter out non-kernel addresses in kern_hyp_va

kern_hyp_va() is idempotent for the hypervisor linear space, which is handy
for nVHE hypervisor callers. This commit adds a check based on PAGE_OFFSET
to filter out non-kernel addresses, extending idempotence to the hypervisor
private range.

> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> index 57f65257bb56d..04d9f59db976f 100644
> --- a/arch/arm64/include/asm/kvm_mmu.h
> +++ b/arch/arm64/include/asm/kvm_mmu.h
> @@ -128,6 +128,9 @@ static __always_inline unsigned long __kern_hyp_va(unsigned long v)
>   * replace the instructions with nops.
>   */
>  #ifndef __KVM_VHE_HYPERVISOR__
> +	if (is_protected_kvm_enabled() && !is_ttbr1_addr(v))
> +		return v;
> +

[Severity: Critical]
Does this bypass address translation for untrusted host-provided pointers
when they are not TTBR1 addresses?

While this makes kern_hyp_va() idempotent for EL2 private addresses,
kern_hyp_va_host() also uses __kern_hyp_va() on unvalidated host arguments.

For example, if the host issues a hypercall like __vgic_v5_save_apr and
passes an EL2 private address:

arch/arm64/kvm/hyp/nvhe/hyp-main.c:handle___vgic_v5_save_apr() {
    ...
    __vgic_v5_save_apr(kern_hyp_va_host(cpu_if));
    ...
}

Because is_ttbr1_addr(v) is false, __kern_hyp_va() will return the EL2
private address unmodified. The handler then dereferences it:

arch/arm64/kvm/hyp/vgic-v5-sr.c:__vgic_v5_save_apr() {
    ...
    cpu_if->vgic_apr = read_sysreg_s(SYS_ICH_APR_EL2);
    ...
}

Could this regression allow an untrusted host (EL1) to execute an arbitrary
write into EL2 private memory and break the pKVM trust boundary?

>  	asm volatile(ALTERNATIVE_CB("and %0, %0, #1\n"         /* mask with va_mask */
>  				    "ror %0, %0, #1\n"         /* rotate to the first tag bit */
>  				    "add %0, %0, #0\n"         /* insert the low 12 bits of the tag */

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261001142849.3367614-1-vdonnefort@google.com?part=11

  reply	other threads:[~2026-10-01 15:35 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-01 14:28 [PATCH v6 00/18] KVM: arm64: Introduce pKVM hypervisor heap allocator Vincent Donnefort
2026-10-01 14:28 ` [PATCH v6 01/18] KVM: arm64: Add pkvm_private_va_range_pa Vincent Donnefort
2026-10-01 14:28 ` [PATCH v6 02/18] KVM: arm64: Add pkvm_remove_mappings Vincent Donnefort
2026-10-01 14:28 ` [PATCH v6 03/18] KVM: arm64: Add pkvm_map_private_va_range Vincent Donnefort
2026-10-01 14:49   ` sashiko-bot
2026-10-01 14:28 ` [PATCH v6 04/18] KVM: arm64: Add a heap allocator for the pKVM hyp Vincent Donnefort
2026-10-01 14:28 ` [PATCH v6 05/18] KVM: arm64: Allow kvm_hyp_memcache usage outside of stage-2 Vincent Donnefort
2026-10-01 14:28 ` [PATCH v6 06/18] KVM: arm64: Add pkvm_hyp_req infrastructure Vincent Donnefort
2026-10-01 14:28 ` [PATCH v6 07/18] KVM: arm64: Add PKVM_HYP_REQ_HYP_ALLOC request Vincent Donnefort
2026-10-01 14:28 ` [PATCH v6 08/18] KVM: arm64: Add reclaim interface for the pKVM heap alloc Vincent Donnefort
2026-10-01 14:28 ` [PATCH v6 09/18] KVM: arm64: Add selftests for the pKVM heap allocator Vincent Donnefort
2026-10-01 15:22   ` sashiko-bot
2026-10-01 14:28 ` [PATCH v6 10/18] KVM: arm64: Add a shrinker for pKVM Vincent Donnefort
2026-10-01 14:28 ` [PATCH v6 11/18] KVM: arm64: Filter out non-kernel addresses in kern_hyp_va Vincent Donnefort
2026-10-01 15:35   ` sashiko-bot [this message]
2026-10-01 14:28 ` [PATCH v6 12/18] KVM: arm64: Move hyp_vm refcount into the structure Vincent Donnefort
2026-10-01 14:28 ` [PATCH v6 13/18] KVM: arm64: Alloc pkvm_hyp_vm using pKVM heap allocator Vincent Donnefort
2026-10-01 15:43   ` sashiko-bot
2026-10-01 14:28 ` [PATCH v6 14/18] KVM: arm64: Alloc pkvm_hyp_vcpu " Vincent Donnefort
2026-10-01 15:46   ` sashiko-bot
2026-10-01 14:28 ` [PATCH v6 15/18] KVM: arm64: Rename vCPU pkvm_memcache to stage2_mc Vincent Donnefort
2026-10-01 14:28 ` [PATCH v6 16/18] KVM: arm64: Reject hyp trace descriptors with fewer CPUs than hyp_nr_cpus Vincent Donnefort
2026-10-01 14:28 ` [PATCH v6 17/18] KVM: arm64: Reject hyp trace descriptors with fewer than 3 pages Vincent Donnefort
2026-10-01 14:28 ` [PATCH v6 18/18] KVM: arm64: Alloc simple_buffer_page using pKVM hyp allocator Vincent Donnefort
2026-10-02 16:39 ` [PATCH v6 00/18] KVM: arm64: Introduce pKVM hypervisor heap allocator Marc Zyngier

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=20261001153512.46EFA1F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=maz@kernel.org \
    --cc=oupton@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vdonnefort@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