Re: [PATCH 05/60] KVM: SVM: Inject MCEs when Restricted Injection is active

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Deferring MCE injection bypasses clearing `vcpu->arch.exception.pending`, triggering a host `WARN_ON_ONCE` and silently dropping the MCE across VM-Exits.
- [High] Priority inversion during event evaluation causes multiple doorbell events to be set concurrently, leading to bitwise corruption during cancellation.
--

commit 92a79deb45b58e8dfe9005d032cb1b5d2cd5935c
Author: Melody Wang <huibo.wang@amd.com>

KVM: SVM: Inject MCEs when Restricted Injection is active

When Restricted Injection is active, only #HV exceptions can be injected
into the SEV-SNP guest. Detect that, and then follow the #HV doorbell
communication from the GHCB specification to inject the MCEs.

> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index 44be2c9b8286d..17168a145d18b 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c

[ ... ]

> @@ -5493,7 +5500,7 @@ void sev_snp_cancel_injection(struct kvm_vcpu *vcpu)
>  
>  	/*
>  	 * KVM only injects a single event each time (prepare_hv_injection),
> -	 * so when events.nmi is true, the vector will be zero
> +	 * so when events.nmi is true, the MCE and vector will be zero.
>  	 */
>  	if (hvdb->events.vector)
>  		svm->vmcb->control.event_inj |= hvdb->events.vector |
> @@ -5502,6 +5509,9 @@ void sev_snp_cancel_injection(struct kvm_vcpu *vcpu)
>  	if (hvdb->events.nmi)
>  		svm->vmcb->control.event_inj |= SVM_EVTINJ_TYPE_NMI;
>  
> +	if (hvdb->events.mce)
> +		svm->vmcb->control.event_inj |= MC_VECTOR | SVM_EVTINJ_TYPE_EXEPT;

[Severity: High]
If multiple events manage to get injected at once, will this bitwise OR
corrupt the exception vector?

For example, if an MCE is blocked but an IRQ is injected, and the injection
is subsequently cancelled, this could bitwise OR MC_VECTOR (0x12) with the
interrupt vector (e.g., 0x0C). For an IRQ vector of 0x0C, this produces 0x1E
combined with SVM_EVTINJ_TYPE_EXEPT, which synthesizes a Security Exception 
(#SX) instead of the intended events.

[ ... ]

> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 0550359ed798f..4b6b628efa219 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -10794,6 +10794,12 @@ static int kvm_check_and_inject_events(struct kvm_vcpu *vcpu,
>  			kvm_update_dr7(vcpu);
>  		}
>  
> +		if (vcpu->arch.exception.vector == MC_VECTOR) {
> +			r = static_call(kvm_x86_mce_allowed)(vcpu);
> +			if (!r)
> +				goto out_except;
> +		}

[Severity: High]
Does jumping to out_except here skip clearing the exception queue?

If mce_allowed() returns 0, bypassing the assignment
vcpu->arch.exception.pending = false leaves the MCE pending.
At the end of kvm_check_and_inject_events(), KVM unconditionally evaluates:

    WARN_ON_ONCE(vcpu->arch.exception.pending);

which can trigger a host warning.

Furthermore, because the exception isn't propagated but remains pending,
is it silently dropped on the next VM-Exit?

svm_complete_interrupts() unconditionally clears it:

    kvm_clear_exception_queue(vcpu);

> +
>  		kvm_inject_exception(vcpu);
>  
>  		vcpu->arch.exception.pending = false;
> @@ -10801,6 +10807,7 @@ static int kvm_check_and_inject_events(struct kvm_vcpu *vcpu,
>  
>  		can_inject = false;
>  	}
> +out_except:
>  
>  	/* Don't inject interrupts if the user asked to avoid doing so */
>  	if (vcpu->guest_debug & KVM_GUESTDBG_BLOCKIRQ)

[Severity: High]
Does jumping to out_except bypass the can_inject = false assignment?

If can_inject remains true when an MCE is blocked, KVM proceeds to evaluate
and inject lower-priority events like NMIs or IRQs.

This breaks the assumption in sev_snp_cancel_injection() that only a single
event is injected at a time, potentially leading to the bitwise corruption
mentioned earlier if an IRQ and a blocked MCE overlap during cancellation.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260608144252.351443-1-joro@8bytes.org?part=5