Re: [PATCH 1/1] KVM: arm64: vgic: Do not remove in-flight LPIs from AP list on disable

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] kvm: arm64: vgic: LR folding resurrects flushed LPIs due to hardware pending state
--

commit b351a9acf6c1fda665727c19bb864d488c3f7d75
Author: Yuchao Zhang <ndaugoing@gmail.com>

KVM: arm64: vgic: Do not remove in-flight LPIs from AP list on disable

This commit fixes a use-after-free crash by preventing the removal of
in-flight LPIs from the AP list during a remote flush. It leaves LPIs
that are currently in a list register on the list, relying on the target
vCPU to naturally prune them after folding.

> diff --git a/arch/arm64/kvm/vgic/vgic.c b/arch/arm64/kvm/vgic/vgic.c
> --- a/arch/arm64/kvm/vgic/vgic.c
> +++ b/arch/arm64/kvm/vgic/vgic.c
> @@ -205,10 +205,12 @@ void vgic_flush_pending_lpis(struct kvm_vcpu *vcpu)
>  		if (irq_is_lpi(vcpu->kvm, irq->intid)) {
>  			raw_spin_lock(&irq->irq_lock);
>  			irq->pending_latch = false;
> -			list_del(&irq->ap_list);
> -			irq->vcpu = NULL;
> +			if (!irq->on_lr) {
> +				list_del(&irq->ap_list);
> +				irq->vcpu = NULL;
> +				deleted |= vgic_put_irq_norelease(vcpu->kvm, irq);
> +			}
>  			raw_spin_unlock(&irq->irq_lock);
> -			deleted |= vgic_put_irq_norelease(vcpu->kvm, irq);
>  		}
>  	}

[Severity: High]
Does skipping the unlink for LR-resident LPIs here prevent them from being
naturally pruned later?

When a guest clears GICR_CTLR.EnableLPIs, all pending LPIs should be
discarded. By leaving in-flight LPIs on the AP list, we rely on the target
vCPU's fold logic to handle them. However, when the vCPU exits,
vgic_v3_fold_lr() reads the hardware List Register and resurrects the
pending state:

arch/arm64/kvm/vgic/vgic-v3.c:vgic_v3_fold_lr() {
        ...
        /* Edge is the only case where we preserve the pending bit */
        if (irq->config == VGIC_CONFIG_EDGE &&
            (val & ICH_LR_PENDING_BIT))
                irq->pending_latch = true;
        ...
}

Because vgic_v3_fold_lr() unconditionally sets irq->pending_latch to true
if the hardware LR has the pending bit set, the flushed LPI's pending state
is restored.

Can this cause the target oracle to evaluate the LPI as still pending,
bypassing the intended flush and keeping the LPI alive for re-injection?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260918024620.83869-1-ndaugoing@gmail.com?part=1