Re: [PATCH 3/4] KVM: x86: Reject KVM_CREATE_IRQCHIP if APIC base is already mapped

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Calling `gfn_to_memslot()` in `KVM_CREATE_IRQCHIP` without holding the SRCU read lock (`kvm->srcu`) or the memslots update lock (`kvm->slots_lock`) leads to a Use-After-Free and triggers a lockdep warning.
--

commit 69e98e42c78858b7858a1956e233c569faf47ae1
Author: Tim Wiederhake <twiederh@redhat.com>

KVM: x86: Reject KVM_CREATE_IRQCHIP if APIC base is already mapped

User space must not map guest memory that covers the default APIC base
address when using an in-kernel irqchip. This commit adds an explicit
check to KVM_CREATE_IRQCHIP so the conflict is reported at the point
where the constraint takes effect.

> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
[ ... ]
> @@ -4413,6 +4413,10 @@ int kvm_arch_vm_ioctl(struct file *filp, unsigned int ioctl, unsigned long arg)
>  		if (kvm->created_vcpus)
>  			goto create_irqchip_unlock;
>  
> +		r = -EEXIST;
> +		if (gfn_to_memslot(kvm, gpa_to_gfn(APIC_DEFAULT_PHYS_BASE)))
> +			goto create_irqchip_unlock;
> +

[Severity: High]
Is it safe to call gfn_to_memslot() in this KVM_CREATE_IRQCHIP path without
holding the kvm->srcu read lock?

Looking at kvm_arch_vm_ioctl() in arch/x86/kvm/x86.c, only kvm->lock is
held when KVM_CREATE_IRQCHIP is executed.

If another thread concurrently calls KVM_SET_USER_MEMORY_REGION, it replaces
the memslots array under kvm->slots_lock and calls synchronize_srcu().
Because KVM_CREATE_IRQCHIP does not take srcu_read_lock(),
synchronize_srcu() won't wait for it.

Could this traversal of the memslots array in gfn_to_memslot() encounter a
freed array and result in a use-after-free, as well as a suspicious RCU usage
lockdep warning?

>  		r = kvm_pic_init(kvm);
>  		if (r)
>  			goto create_irqchip_unlock;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260706092021.3625908-2-twiederh@redhat.com?part=3