Re: [PATCH v5 04/15] KVM: arm64: Add KVM_REQ_RELOAD_STAGE2

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] kvm: arm64: host panic on nVHE due to EL1 access of EL2 sysregs in __load_stage2
--

commit 982e8feb07630370c5da59ed6e47706db5188e18
Author: Leonardo Bras <leo.bras@arm.com>
Subject: KVM: arm64: Add KVM_REQ_RELOAD_STAGE2

This commit adds a vcpu request to exit the guest, reload stage-2, and come
back to the guest, anticipating subsequent patches for S2 HAFDBS and HDBSS.

Link: https://lore.kernel.org/all/20260901171558.2674031-5-leo.bras@arm.com/

> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 0576c2022ef57..d9ad765943d9e 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c

[ ... ]

> @@ -1175,6 +1175,14 @@ static int check_vcpu_requests(struct kvm_vcpu *vcpu)
>  		if (kvm_dirty_ring_check_request(vcpu))
>  			return 0;
>  
> +		if (kvm_check_request(KVM_REQ_RELOAD_STAGE2, vcpu)) {
> +			unsigned long flags;
> +
> +			local_irq_save(flags);
> +			__load_stage2(vcpu->arch.hw_mmu);

[Severity: Critical]
Could this trigger a host kernel panic on systems running in nVHE or
pKVM mode?

In nVHE or pKVM mode, the host kernel runs at EL1. The check_vcpu_requests()
function executes from the host context. If a KVM_REQ_RELOAD_STAGE2 request
is processed here, it calls __load_stage2(), which performs the following:

arch/arm64/include/asm/kvm_mmu.h:__load_stage2() {
    write_sysreg(mmu->vtcr, vtcr_el2);
    write_sysreg(kvm_get_vttbr(mmu), vttbr_el2);
    ...
}

Because vtcr_el2 and vttbr_el2 are EL2 system registers, writing to them
from EL1 will cause an UNDEFINED instruction exception. This causes the CPU
to trap to the hypervisor, which will intentionally panic upon receiving an
unexpected sysreg trap from the host, crashing the system.

Since any unprivileged user with access to /dev/kvm could potentially trigger
a memory region update that sets KVM_REQ_RELOAD_STAGE2, it seems this might
provide a trivial path to trigger a host Denial of Service.

Would it be possible to add a has_vhe() guard here or handle the reload via
a hypercall for non-VHE systems?

> +			local_irq_restore(flags);
> +		}
> +
>  		check_nested_vcpu_requests(vcpu);
>  	}
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260929103655.85107-1-zhengtian10@huawei.com?part=4