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: 61+ 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-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox