Re: [PATCH] KVM: arm64: Pin the host vCPU before adjusting its PC under pKVM

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Double-fetch (TOCTOU) and unvalidated dereference of the host-controlled `vcpu->kvm` pointer creates an arbitrary EL2 memory leak.
--

commit 6841c04b3ad40b222469871cbf4d11537656c507
Author: Fuad Tabba <fuad.tabba@linux.dev>

KVM: arm64: Pin the host vCPU before adjusting its PC under pKVM

This commit pins the host vCPU and its VM around __kvm_adjust_pc() when no
hyp vCPU is loaded, to prevent the hypervisor from panicking by dereferencing
an unmapped host vCPU. A loaded hyp vCPU implies both are already pinned.

> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> index 9a3b92e626adb..e41b4c181eb62 100644
> --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
[ ... ]
> +static void adjust_pc_unloaded(struct kvm_vcpu *host_vcpu)
> +{
> +	struct kvm *host_kvm;
> +
> +	if (hyp_pin_shared_mem(host_vcpu, host_vcpu + 1))
> +		return;
> +
> +	/* The exception entry reads the VM's MTE flag. */
> +	host_kvm = kern_hyp_va(host_vcpu->kvm);
> +	if (!hyp_pin_shared_mem(host_kvm, host_kvm + 1)) {
> +		__kvm_adjust_pc(host_vcpu);

[Severity: Critical]
This is a pre-existing issue, but does this create a double-fetch (TOCTOU)
vulnerability that allows the host kernel to leak arbitrary EL2 memory?

When a vCPU is unloaded, adjust_pc_unloaded() reads host_vcpu->kvm from
host-shared memory (the first fetch) and pins it. When a vCPU is loaded,
handle___kvm_adjust_pc() directly calls __kvm_adjust_pc(host_vcpu) on the
host_vcpu without pinning it here.

In either case, deep inside the __kvm_adjust_pc() call path,
enter_exception64() in arch/arm64/kvm/hyp/exception.c re-reads vcpu->kvm
directly from the host-shared vcpu structure (the second fetch):

	if (kvm_has_mte(kern_hyp_va(vcpu->kvm)))

Because the host kernel can concurrently modify host_vcpu->kvm between the
pin (if any) and this second fetch, it could redirect the pointer to an
arbitrary EL2 address. kvm_has_mte() would then dereference this unvalidated
pointer to test the KVM_ARCH_FLAG_MTE_ENABLED bit (bit 1).

If that bit is set, it updates the PSR_TCO_BIT in the vCPU's CPSR, which gets
written back to host-accessible memory in host_vcpu->arch.ctxt.regs.pstate. By
shifting the base address and observing the result, the host could leak
EL2-private or protected guest memory bit by bit.

> +		hyp_unpin_shared_mem(host_kvm, host_kvm + 1);
> +	}
> +
> +	hyp_unpin_shared_mem(host_vcpu, host_vcpu + 1);
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260914065136.3418404-1-fuad.tabba@linux.dev?part=1