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

[Marc Zyngier <maz@kernel.org>]

On Tue, 16 Jun 2026 19:51:25 +0100,
Oliver Upton <oupton@kernel.org> wrote:
> 
> 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/

Yeah. This thing is getting way too subtle. I'm starting to think that
we may need to use something similar to the MMU notifier sequence
number, and check if anything has happen to the AP list between the
two locked sections.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.