Re: [PATCH v4 12/18] KVM: arm64: Prevent host PC adjustments for protected vCPUs

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] kvm: host DoS via KVM_SET_VCPU_EVENTS and uncleared INCREMENT_PC
- [High] kvm: silently dropped exception injections on non-trap exits for protected guests
--

commit 8bf814727f8778e45c8fb25a3c96ee3b58fc462e
Author: Fuad Tabba <fuad.tabba@linux.dev>

KVM: arm64: Prevent host PC adjustments for protected vCPUs

This commit modifies __kvm_adjust_pc() to leave PC_UPDATE_REQ (including
INCREMENT_PC and PENDING_EXCEPTION) on the host copy for protected VMs. It
introduces kvm_adjust_pc_get() which returns NULL for protected vCPUs,
bypassing the adjustment and leaving the flag clearing to entry/exit handlers.

> diff --git a/arch/arm64/kvm/hyp/exception.c b/arch/arm64/kvm/hyp/exception.c
> index 6e60d890afa4a..93d68b1d38be8 100644
> --- a/arch/arm64/kvm/hyp/exception.c
> +++ b/arch/arm64/kvm/hyp/exception.c
> @@ -353,12 +353,19 @@ static void kvm_inject_exception(struct kvm_vcpu *vcpu)
>   */
>  void __kvm_adjust_pc(struct kvm_vcpu *vcpu)
>  {
> -	if (vcpu_get_flag(vcpu, PENDING_EXCEPTION)) {
> -		kvm_inject_exception(vcpu);
> -		vcpu_clear_flag(vcpu, PENDING_EXCEPTION);
> -		vcpu_clear_flag(vcpu, EXCEPT_MASK);
> -	} else if (vcpu_get_flag(vcpu, INCREMENT_PC)) {
> -		kvm_skip_instr(vcpu);
> -		vcpu_clear_flag(vcpu, INCREMENT_PC);
> +	struct kvm_vcpu *target = kvm_adjust_pc_get(vcpu);
> +
> +	if (!target)
> +		return;

[Severity: Critical]
Can this early return leave INCREMENT_PC uncleared, leading to a host panic?

When an unprivileged host userspace VMM manages a protected VM and sets
SCTLR2_EL1.NMEA=1, a guest MMIO exit causes kvm_handle_mmio_return() to set
INCREMENT_PC on the host vCPU copy.

If entry is then aborted due to a pending signal, we exit to userspace
with -EINTR. Because target is NULL for protected VMs, we return early here
without clearing INCREMENT_PC.

If userspace then calls KVM_SET_VCPU_EVENTS to inject an SError (with
serror_pending=1), serror_is_masked() returns false, which causes
pend_serror_exception() to call kvm_pend_exception(). This hits the assertion:

WARN_ON(vcpu_get_flag(v, INCREMENT_PC));

crashing the host if panic_on_warn is set. While Patch 14 attempts to fix this
by clearing PC_UPDATE_REQ on exit from EL2, INCREMENT_PC is set at EL1 on MMIO
return after the EL2 exit.

[ ... ]
> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> index 00038a162d09b..2fcd3f8cc8fc4 100644
> --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> @@ -644,6 +644,38 @@ static void handle___pkvm_host_mkyoung_guest(struct kvm_cpu_context *host_ctxt)
>  	cpu_reg(host_ctxt, 1) =  ret;
>  }
>  
> +/*
> + * PKVM_HOST_STATE_DIRTY names the authoritative copy, the host's when set.
> + * A loaded protected vCPU takes the request at its next entry instead.
> + */
> +struct kvm_vcpu *kvm_adjust_pc_get(struct kvm_vcpu *vcpu)
> +{
> +	struct pkvm_hyp_vcpu *hyp_vcpu;
> +
> +	if (!is_protected_kvm_enabled())
> +		return vcpu;
> +
> +	hyp_vcpu = pkvm_get_loaded_hyp_vcpu();
> +	if (!hyp_vcpu || vcpu == &hyp_vcpu->vcpu)
> +		return vcpu;
> +
> +	if (pkvm_hyp_vcpu_is_protected(hyp_vcpu))
> +		return NULL;

[Severity: High]
Does deferring exception injection to the entry path cause host-injected
exceptions to be silently dropped on non-trap exits?

If a protected guest exits due to an IRQ (ARM_EXCEPTION_IRQ) and userspace
calls KVM_SET_VCPU_EVENTS with serror_pending=1, PENDING_EXCEPTION is set on
the host vCPU. 

On KVM_RUN, flush_hyp_vcpu() evaluates the exit code and bypasses the
ec_handler for non-trap exits:

	case ARM_EXCEPTION_IRQ:
	case ARM_EXCEPTION_EL1_SERROR:
	case ARM_EXCEPTION_IL:
		break;

This ignores the PENDING_EXCEPTION flag during entry. When the guest exits
again, sync_hyp_vcpu() unconditionally clears PC_UPDATE_REQ (which includes
PENDING_EXCEPTION), permanently losing the injected exception.

[ ... ]

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