Re: [PATCH] KVM: arm64: Handle race between interrupt affinity change and LPI disabling

[Oliver Upton <oupton@kernel.org>]

On Mon, Jun 15, 2026 at 06:33:14PM +0000, sashiko-bot@kernel.org wrote:
> > @@ -795,7 +796,11 @@ static void vgic_prune_ap_list(struct kvm_vcpu *vcpu)
> >  			continue;
> >  		}
> >  
> > -		/* This interrupt looks like it has to be migrated. */
> > +		/*
> > +		 * This interrupt looks like it has to be migrated,
> > +		 * make sure it is kept alive while locks are dropped.
> > +		 */
> > +		vgic_get_irq_ref(irq);
> 
> [Severity: Critical]
> This isn't a bug introduced by this patch, but could the lock-dropping window
> here lead to a double list_del() and a use-after-free under certain race
> conditions?
> 
> When vgic_prune_ap_list() drops the irq and ap_list locks shortly after this
> reference is taken, another thread could concurrently execute
> vgic_flush_pending_lpis() above and remove the irq from the list.
> 
> If a third thread then concurrently injects the same LPI before the locks are
> reacquired, the irq_lock is taken and pending_latch is set to true again.
> 
> When vgic_prune_ap_list() reacquires the locks further down in the function,
> the target_vcpu oracle check will pass because the interrupt is pending again:
> 
> arch/arm64/kvm/vgic/vgic.c:vgic_prune_ap_list() {
>     ...
>     if (target_vcpu == vgic_target_oracle(irq)) {
>         struct vgic_cpu *new_cpu = &target_vcpu->arch.vgic_cpu;
> 
>         list_del(&irq->ap_list);
>         irq->vcpu = target_vcpu;
>     ...
> }
> 
> Because there is no check verifying that irq->vcpu is still equal to the
> source vcpu, does this unconditionally execute list_del() on a list entry
> that has already been removed and poisoned?
> 
> Would this also bypass acquiring a new list reference, leaving the LPI on the
> new list with a deficient reference count if it avoids a crash?

Urgh... Marc, I think we need Hyunwoo's patch in addition to yours. Even
though this 3-way race seems improbable, it does appear possible :/

[*]: https://lore.kernel.org/kvmarm/aiHnI1mu6SGQrgnz@v4bel/

Thanks,
Oliver