From: sashiko-bot@kernel.org
To: "Steffen Eiden" <seiden@linux.ibm.com>
Cc: kvmarm@lists.linux.dev, linux-s390@vger.kernel.org,
"Vasily Gorbik" <gor@linux.ibm.com>,
"Marc Zyngier" <maz@kernel.org>,
kvm@vger.kernel.org, "Alexander Gordeev" <agordeev@linux.ibm.com>,
"Heiko Carstens" <hca@linux.ibm.com>,
"Oliver Upton" <oupton@kernel.org>
Subject: Re: [PATCH v4 01/27] VFIO: take reference to the KVM module
Date: Mon, 06 Jul 2026 09:12:23 +0000 [thread overview]
Message-ID: <20260706091223.E32F31F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260706085229.979525-2-seiden@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] In the VFIO cdev binding path, concurrent or repeated calls to `VFIO_DEVICE_BIND_IOMMUFD` on multiple file descriptors for the same device cause KVM reference leaks and state corruption.
--
commit 298282ceb4d6390cae8f782bcdd7f84408cf4d30
Author: Paolo Bonzini <pbonzini@redhat.com>
VFIO: take reference to the KVM module
This patch modifies VFIO to store a pointer to the KVM module alongside the
KVM pointer. It updates the get/set paths to take and release a module
reference to prevent the KVM module from unloading while in use, in
preparation for removing symbol_get and symbol_put.
> diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
> index ed538aebb0b8e..8289aca97b6be 100644
> --- a/drivers/vfio/vfio_main.c
> +++ b/drivers/vfio/vfio_main.c
[ ... ]
> @@ -448,7 +448,8 @@ void vfio_unregister_group_dev(struct vfio_device *device)
> EXPORT_SYMBOL_GPL(vfio_unregister_group_dev);
>
> #if IS_ENABLED(CONFIG_KVM)
> -void vfio_device_get_kvm_safe(struct vfio_device *device, struct kvm *kvm)
> +void vfio_device_get_kvm_safe(struct vfio_device *device, struct kvm *kvm,
> + struct module *kvm_module)
> {
> void (*pfn)(struct kvm *kvm);
> bool (*fn)(struct kvm *kvm);
> @@ -459,25 +460,31 @@ void vfio_device_get_kvm_safe(struct vfio_device *device, struct kvm *kvm)
> if (!kvm)
> return;
>
> + if (!try_module_get(kvm_module))
> + return;
> +
> pfn = symbol_get(kvm_put_kvm);
> if (WARN_ON(!pfn))
> - return;
> + goto out_put_mod;
>
> fn = symbol_get(kvm_get_kvm_safe);
> - if (WARN_ON(!fn)) {
> - symbol_put(kvm_put_kvm);
> - return;
> - }
> + if (WARN_ON(!fn))
> + goto out_put_sym;
>
> ret = fn(kvm);
> symbol_put(kvm_get_kvm_safe);
> - if (!ret) {
> - symbol_put(kvm_put_kvm);
> - return;
> - }
> + if (!ret)
> + goto out_put_sym;
>
> device->put_kvm = pfn;
> device->kvm = kvm;
> + device->kvm_module = kvm_module;
> + return;
[Severity: High]
This is a pre-existing issue, but can concurrent or repeated calls to
VFIO_DEVICE_BIND_IOMMUFD on multiple file descriptors for the same device
cause KVM reference leaks and state corruption here?
In vfio_device_get_kvm_safe() in drivers/vfio/vfio_main.c, the assignments
above blindly overwrite device->kvm (and now device->kvm_module) without
dropping any existing references.
If a user opens the VFIO device node twice (fd1 and fd2) and binds fd1,
device->kvm is set and the reference is taken. If they then call
VFIO_DEVICE_BIND_IOMMUFD on fd2, this function overwrites the pointers,
leaking the initial KVM and module references.
Furthermore, when vfio_df_open() subsequently fails in the fd2 bind path
because device->open_count > 0, the error path in vfio_df_ioctl_bind_iommufd()
unconditionally calls vfio_device_put_kvm(device). This drops the newly
overwritten reference and clears device->kvm to NULL, entirely breaking the
KVM integration for the still-active fd1.
> +
> +out_put_sym:
> + symbol_put(kvm_put_kvm);
> +out_put_mod:
> + module_put(kvm_module);
> }
>
> void vfio_device_put_kvm(struct vfio_device *device)
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260706085229.979525-1-seiden@linux.ibm.com?part=1
next prev parent reply other threads:[~2026-07-06 9:12 UTC|newest]
Thread overview: 57+ 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 [this message]
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
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-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=20260706091223.E32F31F000E9@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.