All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Aneesh Kumar K.V (Arm)" <aneesh.kumar@kernel.org>
Cc: kvm@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH v7 14/16] iommufd/viommu: Allow PCI TSM backends to provide vIOMMU operations
Date: Thu, 08 Oct 2026 06:19:09 +0000	[thread overview]
Message-ID: <sashiko-outbox-163680@kernel.org> (raw)
In-Reply-To: <20261008055955.4014342-15-aneesh.kumar@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] pci/tsm: Use-After-Free of tsm_dev due to missing device reference count
--

commit 45c3cda47ad9fdb8464c2ba275fcaa5077625b75
Author: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>

iommufd/viommu: Allow PCI TSM backends to provide vIOMMU operations

This commit allows a vIOMMU implementation to be provided by a TEE Security
Manager (TSM) rather than the physical IOMMU driver. It queries the TSM
associated with the target PCI device and resolves the PCI TSM association
under pci_tsm_rwsem while pinning the module.

> diff --git a/drivers/pci/tsm.c b/drivers/pci/tsm.c
> index dca9634f8d5eb..c8603867e09df 100644
> --- a/drivers/pci/tsm.c
> +++ b/drivers/pci/tsm.c

[ ... ]

> @@ -36,6 +38,25 @@ static const struct pci_tsm_ops *to_pci_tsm_ops(struct pci_tsm *tsm)
>  	return tsm->tsm_dev->pci_ops;
>  }
>  
> +struct tsm_dev *pci_tsm_get_device(struct pci_dev *pdev)
> +{
> +	const struct pci_tsm_ops *ops;
> +	struct tsm_dev *tsm_dev;
> +
> +	guard(rwsem_read)(&pci_tsm_rwsem);
> +	if (!pdev->tsm)
> +		return NULL;
> +
> +	tsm_dev = pdev->tsm->tsm_dev;
> +	ops = tsm_dev->pci_ops;
> +	if (!ops->viommu_get_ops)
> +		return NULL;
> +	if (!try_module_get(ops->owner))
> +		return ERR_PTR(-ENODEV);
> +	return tsm_dev;
> +}

[Severity: High]
Does this code need to take a kobject reference on the device via
get_device(&tsm_dev->dev)?

The tsm_dev pointer is returned and stored in viommu->tsm_dev for the
lifetime of the vIOMMU, relying solely on the module pin. 

The doc comment for tsm_get_device() states that backends must not unregister
their TSM independently of module unload. However, in the Linux device model,
a module pin only prevents module removal; it does not prevent a PCI device
from being unbound via sysfs (unbind or remove) or hardware hot-unplug.

If the device is unbound, the driver core forces the driver remove callback
to run, which calls tsm_unregister().

> diff --git a/drivers/virt/coco/tsm-core.c b/drivers/virt/coco/tsm-core.c
> index f791359861020..2fce341ff9231 100644
> --- a/drivers/virt/coco/tsm-core.c
> +++ b/drivers/virt/coco/tsm-core.c

[ ... ]

> @@ -16,6 +26,29 @@ static const struct class tsm_class = {
>  };
>  static DEFINE_IDA(tsm_ida);
>  
> +/**
> + * tsm_get_device() - Pin the TSM attached to a device
> + * @dev: device whose TSM is to be pinned
> + *
> + * A successful lookup pins the backend module. Backends providing vIOMMU
> + * operations must not unregister their TSM independently of module unload.
> + * Return: NULL if no vIOMMU-capable TSM is attached, an error if the module
> + * cannot be pinned, or the TSM device associated with the pinned backend.
> + */
> +struct tsm_dev *tsm_get_device(struct device *dev)
> +{
> +	if (!dev_is_pci(dev))
> +		return NULL;
> +	return pci_tsm_get_device(to_pci_dev(dev));
> +}
> +EXPORT_SYMBOL_GPL(tsm_get_device);
> +
> +void tsm_put_device(struct tsm_dev *tsm_dev)
> +{
> +	module_put(tsm_dev->pci_ops->owner);
> +}

[Severity: High]
Can this dereference freed memory?

When tsm_unregister() is called during an unbind or hot-unplug event, it
invokes put_device(&tsm_dev->dev). Because no extra reference was held when
acquiring the device in pci_tsm_get_device(), the reference count drops to zero
and the tsm_dev object is freed via kfree().

Later, when the vIOMMU is destroyed, iommufd_viommu_destroy() calls
tsm_put_device(viommu->tsm_dev). This dereferences the freed memory to access
tsm_dev->pci_ops->owner, resulting in a use-after-free crash.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261008055955.4014342-1-aneesh.kumar@kernel.org?part=14

  reply	other threads:[~2026-10-08  6:19 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-08  5:59 [PATCH v7 00/16] iommufd: vIOMMUs and TSM guest requests for confidential guests Aneesh Kumar K.V (Arm)
2026-10-08  5:59 ` [PATCH v7 01/16] KVM: Introduce file_to_kvm_<arch>() infrastructure Aneesh Kumar K.V (Arm)
2026-10-08  6:11   ` sashiko-bot
2026-10-08  5:59 ` [PATCH v7 02/16] KVM: Add file back-pointer to struct kvm Aneesh Kumar K.V (Arm)
2026-10-08  6:16   ` sashiko-bot
2026-10-08  5:59 ` [PATCH v7 03/16] KVM: x86: Use file_to_kvm_x86() in SEV Aneesh Kumar K.V (Arm)
2026-10-08  6:07   ` sashiko-bot
2026-10-08  5:59 ` [PATCH v7 04/16] KVM/vfio: Use file-based reference counting for KVM Aneesh Kumar K.V (Arm)
2026-10-08  6:27   ` sashiko-bot
2026-10-08  5:59 ` [PATCH v7 05/16] KVM: Restrict kvm_get_kvm/kvm_put_kvm export to internal KVM modules Aneesh Kumar K.V (Arm)
2026-10-08  6:08   ` sashiko-bot
2026-10-08  5:59 ` [PATCH v7 06/16] KVM: Remove unused file_is_kvm Aneesh Kumar K.V (Arm)
2026-10-08  6:06   ` sashiko-bot
2026-10-08  5:59 ` [PATCH v7 07/16] iommufd/device: Associate KVM file pointer with iommufd_device Aneesh Kumar K.V (Arm)
2026-10-08  6:20   ` sashiko-bot
2026-10-12  8:33     ` Aneesh Kumar K.V
2026-10-12 12:24       ` Jason Gunthorpe
2026-10-08  5:59 ` [PATCH v7 08/16] iommufd/viommu: Keep a reference to the KVM file Aneesh Kumar K.V (Arm)
2026-10-08  6:10   ` sashiko-bot
2026-10-08  5:59 ` [PATCH v7 09/16] tsm: Remove the device from lookup before PCI teardown Aneesh Kumar K.V (Arm)
2026-10-08  6:15   ` sashiko-bot
2026-10-12  9:14     ` Aneesh Kumar K.V
2026-10-12 13:01       ` Jason Gunthorpe
2026-10-13  8:49         ` Aneesh Kumar K.V
2026-10-13 11:57           ` Jason Gunthorpe
2026-10-08  5:59 ` [PATCH v7 10/16] iommufd: Add the vdevice TSM request ioctl Aneesh Kumar K.V (Arm)
2026-10-08  6:10   ` sashiko-bot
2026-10-08  5:59 ` [PATCH v7 11/16] PCI/TSM: Remove the legacy guest request interface Aneesh Kumar K.V (Arm)
2026-10-08  6:11   ` sashiko-bot
2026-10-08  5:59 ` [PATCH v7 12/16] PCI/TSM: Add vIOMMU-bound contexts for vdevices Aneesh Kumar K.V (Arm)
2026-10-08  6:18   ` sashiko-bot
2026-10-08  5:59 ` [PATCH v7 13/16] iommufd/viommu: Select vIOMMU operations before allocation Aneesh Kumar K.V (Arm)
2026-10-08  6:27   ` sashiko-bot
2026-10-12  9:37     ` Aneesh Kumar K.V
2026-10-12 13:05       ` Jason Gunthorpe
2026-10-13  9:11         ` Aneesh Kumar K.V
2026-10-13 12:33           ` Jason Gunthorpe
2026-10-08  5:59 ` [PATCH v7 14/16] iommufd/viommu: Allow PCI TSM backends to provide vIOMMU operations Aneesh Kumar K.V (Arm)
2026-10-08  6:19   ` sashiko-bot [this message]
2026-10-12  9:55     ` Aneesh Kumar K.V
2026-10-08  5:59 ` [PATCH v7 15/16] iommufd: Allow vIOMMUs without a parent HWPT Aneesh Kumar K.V (Arm)
2026-10-08  6:24   ` sashiko-bot
2026-10-08  5:59 ` [PATCH v7 16/16] PCI/TSM: wait for vdevice contexts before removing a DSM Aneesh Kumar K.V (Arm)
2026-10-08  6:25   ` sashiko-bot
2026-10-12 10:01     ` Aneesh Kumar K.V
2026-10-12 13:07       ` Jason Gunthorpe
2026-10-13  9:44         ` Aneesh Kumar K.V
2026-10-13 11:59           ` Jason Gunthorpe
2026-10-12 20:34   ` Bjorn Helgaas

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=sashiko-outbox-163680@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=aneesh.kumar@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-pci@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.