From: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
To: sashiko-reviews@lists.linux.dev
Cc: kvm@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH v8 15/15] PCI/TSM: Wait for users during unregister
Date: Wed, 11 Nov 2026 21:44:09 +0530 [thread overview]
Message-ID: <yq5a7bijtkfi.fsf@kernel.org> (raw)
In-Reply-To: <sashiko-outbox-197810@kernel.org>
sashiko-bot@kernel.org writes:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] PCI/TSM: use-after-free in tsm_unregister() and sev_tsm_uninit()
> - [Low] PCI/TSM: mixing guard() and goto in pci_tsm_context_get() and pci_tsm_init()
> --
>
> commit b2546a16b6b6a681e70bba7a7e4c0fbd2665c584
> Author: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
>
> PCI/TSM: Wait for users during unregister
>
> This commit adds registration_lock and a user reference count to struct
> tsm_dev so that tsm_unregister() and pci_tsm_destroy() wait for active TSM
> users, including IOMMUFD virtual IOMMUs without vDEVICE objects, before
> tearing down PCI connections.
>
>> diff --git a/drivers/crypto/ccp/sev-dev-tsm.c b/drivers/crypto/ccp/sev-dev-tsm.c
>> index 46f2539d2d5ab..5c61ce74ee0f7 100644
>> --- a/drivers/crypto/ccp/sev-dev-tsm.c
>> +++ b/drivers/crypto/ccp/sev-dev-tsm.c
>> @@ -392,8 +392,8 @@ void sev_tsm_init_locked(struct sev_device *sev, void *tio_status_page)
>>
>> void sev_tsm_uninit(struct sev_device *sev)
>> {
>> - if (sev->tsmdev)
>> - tsm_unregister(sev->tsmdev);
>> + if (sev->tsmdev && WARN_ON(tsm_unregister(sev->tsmdev)))
>> + return;
>>
>> sev->tsmdev = NULL;
>> }
>
> [Severity: High]
> Can a concurrent call to sev_tsm_uninit() while tsm_unregister() is waiting
> for TSM users trigger a use-after-free or premature teardown?
>
> In drivers/crypto/ccp/sev-dev.c, sev_firmware_shutdown() invokes
> sev_tsm_uninit() outside sev_cmd_mutex:
>
> drivers/crypto/ccp/sev-dev.c:sev_firmware_shutdown() {
> if (sev->tio_status)
> sev_tsm_uninit(sev);
>
> sev_snp_unregister_verify_mitigation(sev);
>
> mutex_lock(&sev_cmd_mutex);
>
> __sev_firmware_shutdown(sev, false);
>
> kfree(sev->tio_status);
> sev->tio_status = NULL;
>
> mutex_unlock(&sev_cmd_mutex);
> }
>
> Because tsm_unregister() now sleeps in tsm_wait_for_users() and
> sev->tsmdev is only cleared after tsm_unregister() returns, a concurrent
> caller of sev_firmware_shutdown() (such as sev_platform_shutdown() racing
> with sev_dev_destroy() or sev_pci_exit()) can see non-NULL sev->tio_status
> and sev->tsmdev and call tsm_unregister(sev->tsmdev) a second time.
>
> Additionally, if tsm_unregister() returns -ENODEV here, sev_tsm_uninit()
> returns early without clearing sev->tsmdev, and sev_firmware_shutdown()
> proceeds to run __sev_firmware_shutdown() and free sev->tio_status while
> the first caller is still blocked in tsm_wait_for_users() or disconnecting
> PCI devices in pci_tsm_unregister().
>
[ ... 132 lines skipped ... ]
>
> [Severity: High]
> Can the tsm_dev->unregistering check in tsm_unregister() cause a
> use-after-free on tsm_dev when two callers race to unregister the same
> device?
>
> tsm_register() initializes tsm_dev->dev with a single registration device
> reference. When a first caller enters tsm_unregister(), it holds
> down_write(&tsm_dev->registration_lock) across device_del(),
> tsm_wait_for_users(), and pci_tsm_unregister().
>
> If a second caller enters tsm_unregister() while the first caller is
> waiting for users to drain, the second caller blocks in
> down_write(&tsm_dev->registration_lock) without holding a device reference
> on tsm_dev->dev. Once all user references have been dropped and the first
> caller finishes:
>
> up_write(&tsm_dev->registration_lock);
> put_device(&tsm_dev->dev);
>
> put_device(&tsm_dev->dev) drops the final reference and frees tsm_dev via
> tsm_release(), while the second caller wakes from
> down_write(&tsm_dev->registration_lock), reads tsm_dev->unregistering, and
> calls up_write(&tsm_dev->registration_lock) on the freed tsm_dev.
>
I consider both issues pre-existing. The SEV code should ensure that
concurrent calls to tsm_unregister() hold additional references so that
tsm_dev remains valid. Can this be fixed separately from this series?
-aneesh
prev parent reply other threads:[~2026-11-11 16:14 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 16:16 [PATCH v8 00/15] iommufd: TSM-backed virtual IOMMUs for confidential guests Aneesh Kumar K.V (Arm)
2026-11-04 16:16 ` [PATCH v8 01/15] PCI/TSM: Move core code into its own directory Aneesh Kumar K.V (Arm)
2026-11-04 16:23 ` sashiko-bot
2026-11-05 12:24 ` kernel test robot
2026-11-04 16:16 ` [PATCH v8 02/15] virt: coco: tsm: Remove the device from lookup before PCI teardown Aneesh Kumar K.V (Arm)
2026-11-04 16:27 ` sashiko-bot
2026-11-06 7:04 ` Tian, Kevin
2026-11-12 11:14 ` Alexey Kardashevskiy
2026-11-04 16:16 ` [PATCH v8 03/15] virt: coco: tsm: Complete PCI registration before publishing the device Aneesh Kumar K.V (Arm)
2026-11-04 16:32 ` sashiko-bot
2026-11-12 11:41 ` Alexey Kardashevskiy
2026-11-04 16:16 ` [PATCH v8 04/15] virt: coco: tsm: Require PCI operations when registering a TSM Aneesh Kumar K.V (Arm)
2026-11-04 16:36 ` sashiko-bot
2026-11-04 16:16 ` [PATCH v8 05/15] iommufd/device: Associate KVM file pointer with iommufd_device Aneesh Kumar K.V (Arm)
2026-11-04 16:40 ` sashiko-bot
2026-11-06 7:09 ` Tian, Kevin
2026-11-04 16:16 ` [PATCH v8 06/15] iommufd/device: Hold a KVM file reference for the device lifetime Aneesh Kumar K.V (Arm)
2026-11-04 16:43 ` sashiko-bot
2026-11-06 7:16 ` Tian, Kevin
2026-11-12 12:25 ` Alexey Kardashevskiy
2026-11-12 17:40 ` Jason Gunthorpe
2026-11-04 16:16 ` [PATCH v8 07/15] iommufd/viommu: Keep a reference to the KVM file Aneesh Kumar K.V (Arm)
2026-11-04 16:35 ` Jacob Pan
2026-11-04 16:46 ` sashiko-bot
2026-11-06 7:17 ` Tian, Kevin
2026-11-04 16:16 ` [PATCH v8 08/15] iommufd: Add a vDEVICE operation ioctl framework Aneesh Kumar K.V (Arm)
2026-11-04 16:54 ` sashiko-bot
2026-11-06 7:24 ` Tian, Kevin
2026-11-04 16:16 ` [PATCH v8 09/15] PCI/TSM: Remove the legacy guest request interface Aneesh Kumar K.V (Arm)
2026-11-04 16:56 ` sashiko-bot
2026-11-04 16:16 ` [PATCH v8 10/15] PCI/TSM: Add vIOMMU-bound device contexts Aneesh Kumar K.V (Arm)
2026-11-04 17:07 ` sashiko-bot
2026-11-06 7:33 ` Tian, Kevin
2026-11-11 16:24 ` Aneesh Kumar K.V
2026-11-04 16:16 ` [PATCH v8 11/15] iommufd/viommu: Select vIOMMU operations before allocation Aneesh Kumar K.V (Arm)
2026-11-04 17:14 ` sashiko-bot
2026-11-05 9:10 ` kernel test robot
2026-11-05 14:49 ` kernel test robot
2026-11-06 7:47 ` Tian, Kevin
2026-11-12 10:31 ` Aneesh Kumar K.V
2026-11-04 16:16 ` [PATCH v8 12/15] iommufd/viommu: Allow PCI TSM backends to provide vIOMMU operations Aneesh Kumar K.V (Arm)
2026-11-04 17:19 ` sashiko-bot
2026-11-04 23:23 ` Jacob Pan
2026-11-05 0:49 ` Jason Gunthorpe
2026-11-05 17:16 ` Jacob Pan
2026-11-06 8:03 ` Tian, Kevin
2026-11-09 18:49 ` Jason Gunthorpe
2026-11-06 7:56 ` Tian, Kevin
2026-11-12 10:51 ` Aneesh Kumar K.V
2026-11-04 16:16 ` [PATCH v8 13/15] iommufd/viommu: Allow vIOMMUs without a parent HWPT Aneesh Kumar K.V (Arm)
2026-11-04 17:25 ` sashiko-bot
2026-11-04 19:03 ` Nicolin Chen
2026-11-04 19:31 ` Jason Gunthorpe
2026-11-05 5:28 ` Aneesh Kumar K.V
2026-11-05 17:44 ` Nicolin Chen
2026-11-05 18:21 ` Jason Gunthorpe
2026-11-05 18:40 ` Nicolin Chen
2026-11-05 20:07 ` Jason Gunthorpe
2026-11-04 16:16 ` [PATCH v8 14/15] PCI/TSM: Wait for device contexts before removing a DSM Aneesh Kumar K.V (Arm)
2026-11-04 17:41 ` sashiko-bot
2026-11-04 16:16 ` [PATCH v8 15/15] PCI/TSM: Wait for users during unregister Aneesh Kumar K.V (Arm)
2026-11-04 18:00 ` sashiko-bot
2026-11-11 16:14 ` Aneesh Kumar K.V [this message]
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=yq5a7bijtkfi.fsf@kernel.org \
--to=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.