Re: [PATCH v5 11/18] KVM: arm64: Filter out non-kernel addresses in kern_hyp_va

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] The patch modifies `__kern_hyp_va()` to return non-TTBR1 pointers unmodified, allowing a malicious host to trick the hypervisor into dereferencing EL2 private memory instead of host memory, completely bypassing pKVM isolation.
--

commit 1e2548767418379244f938decad822feafe32b7b
Author: Vincent Donnefort <vdonnefort@google.com>

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

This patch updates __kern_hyp_va() to filter out non-kernel addresses based
on PAGE_OFFSET. When protected mode is enabled, it returns the input address
unmodified if it is not a TTBR1 address, aiming to handle addresses from the
hypervisor private range.

> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> index 6eae7e7e2a684..d89864c4b961b 100644
> --- a/arch/arm64/include/asm/kvm_mmu.h
> +++ b/arch/arm64/include/asm/kvm_mmu.h
> @@ -126,6 +126,9 @@ static __always_inline unsigned long __kern_hyp_va(unsigned long v)
>   * replace the instructions with `nop`s.
>   */
>  #ifndef __KVM_VHE_HYPERVISOR__
> +	if (is_protected_kvm_enabled() && !is_ttbr1_addr(v))
> +		return v;
> +

[Severity: Critical]
Does this bypass the mandatory translation for non-TTBR1 addresses, breaking
the guarantee that kern_hyp_va() always restricts the output to the EL2 linear
map?

Since the pKVM threat model treats the host kernel as an adversary against
hypervisor integrity and guest confidentiality, returning the address
unmodified could allow a malicious host to trick the hypervisor into
dereferencing EL2 private memory instead of host memory.

For instance, if a malicious host passes an EL2 private virtual address
(which is below PAGE_OFFSET) to a hypercall, is_ttbr1_addr() would evaluate
to false. The address would be returned unmodified, leading to potential
reads or writes in EL2 private memory.

Could this lead to exploitation in paths such as:

arch/arm64/kvm/hyp/nvhe/hyp-main.c:handle___kvm_tlb_flush_vmid_ipa() {
    ...
    __kvm_tlb_flush_vmid_ipa(kern_hyp_va(mmu), ipa, level);
    ...
}

In this case, EL2 could read out of bounds from its own private memory.

Similarly, during a hypercall like __KVM_HOST_SMCCC_FUNC___vgic_v5_save_apr:

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

Could this result in __vgic_v5_save_apr() writing hypervisor registers into
EL2 private memory, allowing privilege escalation from EL1 to EL2?

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