From: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
To: sashiko-reviews@lists.linux.dev
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v5 1/5] vfio: cache KVM VM file references instead of raw struct kvm pointers
Date: Tue, 26 May 2026 13:41:08 +0530 [thread overview]
Message-ID: <yq5ay0h6si8z.fsf@kernel.org> (raw)
In-Reply-To: <20260525164753.E54191F000E9@smtp.kernel.org>
sashiko-bot@kernel.org writes:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] Concurrent BIND_IOMMUFD ioctls on multiple cdev file descriptors for the same device unconditionally overwrite device->kvm_file, leading to reference leaks and Use-After-Free.
> --
>
> commit 9a5907f1fb1069cc250703cfb404e5a7be33bf23
> Author: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
>
> vfio: cache KVM VM file references instead of raw struct kvm pointers
>
> This commit switches VFIO to track the VM's struct file instead of raw
> struct kvm pointers to manage the KVM VM lifetime. This change allows
> VFIO and iommufd to use normal file references for VM lifetime rather
> than relying on KVM's internal refcounting.
>
>> diff --git a/drivers/vfio/device_cdev.c b/drivers/vfio/device_cdev.c
>> index 54abf312cf049..ca75ab8eb7bd7 100644
>> --- a/drivers/vfio/device_cdev.c
>> +++ b/drivers/vfio/device_cdev.c
>
> [ ... ]
>
>> @@ -133,10 +133,10 @@ long vfio_df_ioctl_bind_iommufd(struct vfio_device_file *df,
>> }
>>
>> /*
>> - * Before the device open, get the KVM pointer currently
>> - * associated with the device file (if there is) and obtain
>> - * a reference. This reference is held until device closed.
>> - * Save the pointer in the device for use by drivers.
>> + * Before the device open, get the VM struct file currently
>> + * associated with the device file (if there is one) and obtain a
>> + * reference. This reference is held until the device is closed.
>> + * Save the file in the device for use by drivers.
>> */
>> vfio_df_get_kvm_safe(df);
>>
>
> [Severity: High]
> This isn't a bug introduced by this patch, but does this unconditionally
> overwrite device->kvm_file if concurrent BIND_IOMMUFD ioctls are called on
> multiple cdev file descriptors for the same device?
>
> If a user opens a VFIO device cdev twice, getting two distinct file
> descriptors (df1 and df2) for the same device, and successfully binds df1
> to IOMMUFD:
>
> - device->kvm_file is set (with an extra refcount)
> - device->open_count increments to 1
>
> When the user attempts to bind df2, the check for df->access_granted only
> checks df2, so execution proceeds.
>
> Calling vfio_df_get_kvm_safe(df2) will overwrite device->kvm_file with
> df2's KVM file. Could the previous file reference from df1 be leaked because
> no fput() is called?
>
> If vfio_df_open(df2) then returns an error (because device->open_count is 1),
> the error path jumps to out_put_kvm and calls vfio_device_put_kvm(device).
> This drops the new reference and clears device->kvm_file to NULL.
>
> This leaves df1 bound and functional, but its KVM association is destroyed.
> When df1 is eventually closed, hardware drivers like vfio_pci_zdev that check
> vfio_device_get_kvm() will see a NULL pointer and skip their KVM
> unregistration hooks. Can this leave KVM hooked to a closed device,
> potentially leading to a use-after-free when KVM accesses it?
>
I guess we can fix this by
modified drivers/vfio/device_cdev.c
@@ -115,8 +115,8 @@ long vfio_df_ioctl_bind_iommufd(struct vfio_device_file *df,
return ret;
mutex_lock(&device->dev_set->lock);
- /* one device cannot be bound twice */
- if (df->access_granted) {
+ /* The cdev path only supports one bound/open device fd. */
+ if (df->access_granted || device->open_count) {
ret = -EINVAL;
goto out_unlock;
}
next prev parent reply other threads:[~2026-05-26 8:11 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-25 15:48 [PATCH v5 0/5] Add iommufd ioctls to support TSM operations Aneesh Kumar K.V (Arm)
2026-05-25 15:48 ` [PATCH v5 1/5] vfio: cache KVM VM file references instead of raw struct kvm pointers Aneesh Kumar K.V (Arm)
2026-05-25 16:47 ` sashiko-bot
2026-05-26 8:11 ` Aneesh Kumar K.V [this message]
2026-05-26 10:52 ` Anthony Krowiak
2026-05-25 15:48 ` [PATCH v5 2/5] iommufd/device: Associate KVM file pointer with iommufd_device Aneesh Kumar K.V (Arm)
2026-05-25 20:33 ` sashiko-bot
2026-05-26 8:17 ` Aneesh Kumar K.V
2026-05-25 15:48 ` [PATCH v5 3/5] iommufd/viommu: Keep a reference to the KVM file Aneesh Kumar K.V (Arm)
2026-05-25 15:48 ` [PATCH v5 4/5] iommufd/tsm: add vdevice TSM bind/unbind ioctl Aneesh Kumar K.V (Arm)
2026-05-25 21:44 ` sashiko-bot
2026-05-25 15:48 ` [PATCH v5 5/5] iommufd/vdevice: add TSM request ioctl Aneesh Kumar K.V (Arm)
2026-05-25 22:18 ` sashiko-bot
2026-05-26 8:18 ` Aneesh Kumar K.V
2026-05-27 0:16 ` Alexey Kardashevskiy
2026-05-27 6:17 ` Dan Williams (nvidia)
2026-05-27 6:56 ` Tian, Kevin
2026-05-27 12:51 ` Jason Gunthorpe
2026-05-27 15:34 ` Aneesh Kumar K.V
2026-05-27 17:49 ` Aneesh Kumar K.V
2026-05-27 22:49 ` Dan Williams (nvidia)
2026-06-02 5:10 ` Aneesh Kumar K.V
2026-06-08 20:58 ` Dan Williams (nvidia)
2026-06-09 8:59 ` Aneesh Kumar K.V
2026-06-09 10:49 ` Alexey Kardashevskiy
2026-06-02 8:40 ` Alexey Kardashevskiy
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=yq5ay0h6si8z.fsf@kernel.org \
--to=aneesh.kumar@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.