Re: [PATCH] KVM: PPC: Book3S HV: Set irqfd->producer only on success

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [Critical] On x86, `kvm_arch_irq_bypass_add_producer()` leaves a dangling `irqfd->producer` pointer on failure, causing an exploitable Use-After-Free during subsequent IRQ routing updates.
- [High] On ARM64, `irqfd->producer` is never assigned, rendering `kvm_arch_update_irqfd_routing()` dead code and causing stale GICv4 VLPI forwarding state.
--

--- Patch [1]: [PATCH] KVM: PPC: Book3S HV: Set irqfd->producer only on success ---
commit cb5d1de2b1bfd4aded0e24ab02c54c7d0fbd846f
Author: leixiang <leixiang@kylinos.cn>

KVM: PPC: Book3S HV: Set irqfd->producer only on success

This patch updates kvmppc_irq_bypass_add_producer_hv to only set
irqfd->producer when kvmppc_set_passthru_irq succeeds. This prevents
leaving a dangling pointer if the bypass manager fails to register the
producer.

> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 61dbeea317f3b..ff7b256291250 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -6111,12 +6111,12 @@ static int kvmppc_irq_bypass_add_producer_hv(struct irq_bypass_consumer *cons,
>  	struct kvm_kernel_irqfd *irqfd =
>  		container_of(cons, struct kvm_kernel_irqfd, consumer);
>  
> -	irqfd->producer = prod;
> -
>  	ret = kvmppc_set_passthru_irq(irqfd->kvm, prod->irq, irqfd->gsi);
>  	if (ret)
>  		pr_info("kvmppc_set_passthru_irq (irq %d, gsi %d) fails: %d\n",
>  			prod->irq, irqfd->gsi, ret);
> +	else
> +		irqfd->producer = prod;

[Severity: Critical]
This is a pre-existing regression and was not introduced by the patch under
review, but does x86 suffer from the exact same logic regression being fixed
here?

Looking at kvm_arch_irq_bypass_add_producer() in arch/x86/kvm/irq.c, it
sets irqfd->producer unconditionally before calling kvm_pi_update_irte():

arch/x86/kvm/irq.c:kvm_arch_irq_bypass_add_producer() {
    ...
    spin_lock_irq(&kvm->irqfds.lock);
    irqfd->producer = prod;
    
    if (!kvm->arch.nr_possible_bypass_irqs++)
        kvm_x86_call(pi_start_bypass)(kvm);
        
    if (irqfd->irq_entry.type == KVM_IRQ_ROUTING_MSI) {
        ret = kvm_pi_update_irte(irqfd, &irqfd->irq_entry);
        if (ret)
            kvm->arch.nr_possible_bypass_irqs--;
    }
    spin_unlock_irq(&kvm->irqfds.lock);
    
    return ret;
}

If kvm_pi_update_irte() fails, it returns an error but leaves
irqfd->producer dangling.

Later, if the guest updates IRQ routing, KVM might invoke
kvm_arch_update_irqfd_routing() which calls kvm_pi_update_irte() again,
which uses the freed pointer:

arch/x86/kvm/irq.c:kvm_pi_update_irte() {
    unsigned int host_irq = irqfd->producer->irq;
    ...
}

Should x86 also clear irqfd->producer on failure?

[Severity: High]
This isn't a regression introduced by this patch, but while reviewing this
change I noticed that ARM64 seems to have the opposite problem.

In arch/arm64/kvm/arm.c, kvm_arch_irq_bypass_add_producer() completely omits
setting irqfd->producer:

arch/arm64/kvm/arm.c:kvm_arch_irq_bypass_add_producer() {
    struct kvm_kernel_irqfd *irqfd =
        container_of(cons, struct kvm_kernel_irqfd, consumer);
    struct kvm_kernel_irq_routing_entry *irq_entry = &irqfd->irq_entry;

    if (irq_entry->type != KVM_IRQ_ROUTING_MSI)
        return 0;

    return kvm_vgic_v4_set_forwarding(irqfd->kvm, prod->irq,
                                      &irqfd->irq_entry);
}

Because irqfd->producer is never assigned, does this render
kvm_arch_update_irqfd_routing() dead code on ARM64?

arch/arm64/kvm/arm.c:kvm_arch_update_irqfd_routing() {
    ...
    return kvm_vgic_v4_unset_forwarding(irqfd->kvm, irqfd->producer->irq);
}

Since the core KVM code in virt/kvm/eventfd.c relies on irqfd->producer being
non-NULL to propagate routing updates, this looks like it could leave
hardware forwarding in a stale state.

Should ARM64 be updated to set irqfd->producer on success?

>  
>  	return ret;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709055755.31297-1-leixiang@kylinos.cn?part=1