All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Steffen Eiden" <seiden@linux.ibm.com>
Cc: kvm@vger.kernel.org, "Oliver Upton" <oupton@kernel.org>,
	"Alexander Gordeev" <agordeev@linux.ibm.com>,
	"Heiko Carstens" <hca@linux.ibm.com>,
	"Vasily Gorbik" <gor@linux.ibm.com>,
	kvmarm@lists.linux.dev, "Marc Zyngier" <maz@kernel.org>,
	linux-s390@vger.kernel.org
Subject: Re: [PATCH v4 03/27] KVM, vfio: remove symbol_get(kvm_put_kvm) from vfio
Date: Mon, 06 Jul 2026 09:25:50 +0000	[thread overview]
Message-ID: <20260706092550.A6C801F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260706085229.979525-4-seiden@linux.ibm.com>

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

Pre-existing issues:
- [High] Concurrent or subsequent bindings of cdev file descriptors to the same VFIO device overwrite the `device->kvm` and `device->kvm_module` pointers without dropping the previous reference, causing a KVM instance memory leak and premature KVM reference drop.
- [High] The architecture-specific KVM module (e.g., kvm-intel.ko) can be unloaded while VFIO still holds a reference to a KVM instance, leading to execution of freed memory when the instance is eventually destroyed.
--

commit 31b847131145e41ad6d50358b1c90ea462e38022
Author: Paolo Bonzini <pbonzini@redhat.com>

KVM, vfio: remove symbol_get(kvm_put_kvm) from vfio
    
Right now, KVM and VFIO are using symbol_get to access each other's
symbols because of a circular reference between the modules, as well
as to avoid loading them unnecessarily.
    
The remaining use in VFIO is for kvm_put_kvm, which is not inline
because it needs to call kvm_destroy_vm.  However, storing the
address of kvm_destroy_vm in the "struct kvm" is enough to remove
the dependency from VFIO.

> diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
> index b7b8b45f1cec2..6bddea4d384ff 100644
> --- a/drivers/vfio/vfio_main.c
> +++ b/drivers/vfio/vfio_main.c

[ ... ]

> @@ -451,9 +451,6 @@ EXPORT_SYMBOL_GPL(vfio_unregister_group_dev);
>  void vfio_device_get_kvm_safe(struct vfio_device *device, struct kvm *kvm,
>  			      struct module *kvm_module)
>  {
> -	void (*pfn)(struct kvm *kvm);
> -	bool ret;
> -
>  	lockdep_assert_held(&device->dev_set->lock);
>  
>  	if (!kvm)
> @@ -462,21 +459,13 @@ void vfio_device_get_kvm_safe(struct vfio_device *device, struct kvm *kvm,
>  	if (!try_module_get(kvm_module))
>  		return;

[Severity: High]
This isn't a bug introduced by this patch, but does pinning only the generic
kvm.ko module leave us vulnerable to the architecture-specific module being
unloaded?

When VFIO acquires a reference via try_module_get(kvm_module), it doesn't
pin the architecture module (e.g., kvm-intel.ko). If userspace closes the
KVM fds, the VFS reference count drops to 0, allowing an administrator to
unload the arch module. 

Since VFIO still holds a reference to the struct kvm, when VFIO later drops
its reference, KVM destruction proceeds:

kvm_destroy_vm()
    kvm_arch_pre_destroy_vm(kvm);
    ...
    kvm_arch_destroy_vm(kvm);

Could these calls into the architecture-specific teardown execute unmapped
memory if the arch module has already been unloaded?

> -	pfn = symbol_get(kvm_put_kvm);
> -	if (WARN_ON(!pfn))
> +	if (!kvm_get_kvm_safe(kvm))
>  		goto out_put_mod;
>  
> -	ret = kvm_get_kvm_safe(kvm);
> -	if (!ret)
> -		goto out_put_sym;
> -
> -	device->put_kvm = pfn;
>  	device->kvm = kvm;
>  	device->kvm_module = kvm_module;

[Severity: High]
This is a pre-existing issue, but if multiple cdev file descriptors are
opened for the same VFIO device, does this overwrite device->kvm without
dropping the previous reference?

For instance, if vfio_df_get_kvm_safe() is called successfully on a second
file descriptor, but then vfio_df_open() fails because
device->open_count != 0:

drivers/vfio/device_cdev.c:vfio_df_ioctl_bind_iommufd() {
    ...
    vfio_df_get_kvm_safe(df);
    
    ret = vfio_df_open(df);
    if (ret)
        goto out_put_kvm;
    ...
}

Would this leak the first KVM instance reference since device->kvm is
unconditionally overwritten here?

Additionally, if the second fd has no KVM instance associated, wouldn't the
error path's call to vfio_device_put_kvm() prematurely drop the original
reference and clear device->kvm?

>  	return;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260706085229.979525-1-seiden@linux.ibm.com?part=3

  reply	other threads:[~2026-07-06  9:25 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-06  8:52 [PATCH v4 00/27] KVM: s390: Introduce arm64 KVM Steffen Eiden
2026-07-06  8:52 ` [PATCH v4 01/27] VFIO: take reference to the KVM module Steffen Eiden
2026-07-06  9:12   ` sashiko-bot
2026-07-06 19:53   ` Jason Gunthorpe
2026-07-06 21:12     ` Sean Christopherson
2026-07-07  7:39       ` Steffen Eiden
2026-07-06  8:52 ` [PATCH v4 02/27] KVM, vfio: remove symbol_get(kvm_get_kvm_safe) from vfio Steffen Eiden
2026-07-06  8:52 ` [PATCH v4 03/27] KVM, vfio: remove symbol_get(kvm_put_kvm) " Steffen Eiden
2026-07-06  9:25   ` sashiko-bot [this message]
2026-07-06  8:52 ` [PATCH v4 04/27] KVM: Make device name configurable Steffen Eiden
2026-07-06  9:14   ` sashiko-bot
2026-07-06  8:52 ` [PATCH v4 05/27] KVM: Remove KVM_MMIO as config option Steffen Eiden
2026-07-06 20:53   ` Marc Zyngier
2026-07-06  8:52 ` [PATCH v4 06/27] arm64: Use proper include variant Steffen Eiden
2026-07-06  8:52 ` [PATCH v4 07/27] arm64: Prepare sharing arm64 headers with s390 Steffen Eiden
2026-07-06 21:22   ` Marc Zyngier
2026-07-06  8:52 ` [PATCH v4 08/27] KVM: arm64: Prepare sharing arm64 code " Steffen Eiden
2026-07-06  9:21   ` sashiko-bot
2026-07-06 21:28   ` Marc Zyngier
2026-07-07  7:20     ` Steffen Eiden
2026-07-06  8:52 ` [PATCH v4 09/27] KVM: arm64: Access elements of vcpu_gp_regs individually Steffen Eiden
2026-07-06 17:44   ` Marc Zyngier
2026-07-06  8:52 ` [PATCH v4 10/27] KVM: arm64: Refactor core-reset into a separate function Steffen Eiden
2026-07-06  8:52 ` [PATCH v4 11/27] s390: Use arm64 headers Steffen Eiden
2026-07-06  9:31   ` sashiko-bot
2026-07-06  8:52 ` [PATCH v4 12/27] KVM: s390: Use arm64 code Steffen Eiden
2026-07-06  9:26   ` sashiko-bot
2026-07-06  8:52 ` [PATCH v4 13/27] KVM: s390: Prepare KVM/s390 for a second KVM module Steffen Eiden
2026-07-06  8:52 ` [PATCH v4 14/27] KVM: s390: Move s390 kvm code into a subdirectory Steffen Eiden
2026-07-06  9:35   ` sashiko-bot
2026-07-06  8:52 ` [PATCH v4 15/27] KVM: S390: Prepare gmap for a second KVM implementation Steffen Eiden
2026-07-06  9:36   ` sashiko-bot
2026-07-06  8:52 ` [PATCH v4 16/27] KVM: s390: gmap: Refactor storage key and CMMA code into separate files Steffen Eiden
2026-07-06  8:52 ` [PATCH v4 17/27] KVM: s390: Refactor prefix handling into a separate file Steffen Eiden
2026-07-06  8:52 ` [PATCH v4 18/27] KVM: s390: Prepare kvm-s390 for a second kvm module Steffen Eiden
2026-07-06  8:52 ` [PATCH v4 19/27] s390: Introduce Start Arm Execution instruction Steffen Eiden
2026-07-06 11:17   ` Janosch Frank
2026-07-06 11:30     ` Christian Borntraeger
2026-07-06 11:58       ` Steffen Eiden
2026-07-06 11:53     ` Steffen Eiden
2026-07-06  8:52 ` [PATCH v4 20/27] KVM: s390: arm64: Introduce host definitions Steffen Eiden
2026-07-06  8:52 ` [PATCH v4 21/27] s390/hwcaps: Report SAE support as hwcap Steffen Eiden
2026-07-06 11:50   ` Janosch Frank
2026-07-06  8:52 ` [PATCH v4 22/27] KVM: s390: Add basic arm64 kvm module Steffen Eiden
2026-07-06  9:51   ` sashiko-bot
2026-07-06  8:52 ` [PATCH v4 23/27] KVM: s390: arm64: Implement required functions Steffen Eiden
2026-07-06  9:55   ` sashiko-bot
2026-07-06 12:15   ` Janosch Frank
2026-07-06 20:35   ` Marc Zyngier
2026-07-06  8:52 ` [PATCH v4 24/27] KVM: s390: arm64: Implement vm/vcpu create destroy Steffen Eiden
2026-07-06 10:04   ` sashiko-bot
2026-07-07 15:10   ` Marc Zyngier
2026-07-06  8:52 ` [PATCH v4 25/27] KVM: s390: arm64: Implement vCPU IOCTLs Steffen Eiden
2026-07-06 10:16   ` sashiko-bot
2026-07-06  8:52 ` [PATCH v4 26/27] KVM: s390: arm64: Implement basic page fault handler Steffen Eiden
2026-07-06 10:03   ` sashiko-bot
2026-07-06  8:52 ` [PATCH v4 27/27] KVM: s390: arm64: Enable KVM_ARM64 config and Kbuild Steffen Eiden
2026-07-06 10:07   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260706092550.A6C801F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=agordeev@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-s390@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=oupton@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=seiden@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.