[PATCH] PCI/TSM: fix use-after-free in find_dsm_dev()

[PATCH] PCI/TSM: fix use-after-free in find_dsm_dev()

[Wentao Liang]

In find_dsm_dev(), pf0 is obtained via pf0_dev_get() which returns a
reference-counted pointer.  It is declared with __free(pci_dev_put),
so pci_dev_put() will be called when the variable goes out of scope.
Returning 'pf0' directly while it still has __free cleanup causes the
reference to be dropped before the caller can use the pointer, leading
to a use-after-free.

Fix by using return no_free_ptr(pf0) to suppress the automatic
cleanup and properly transfer ownership to the caller.

Fixes: 3225f52cde56 ("PCI/TSM: Establish Secure Sessions and Link Encryption")
Cc: stable@vger.kernel.org
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
---
 drivers/pci/tsm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/tsm.c b/drivers/pci/tsm.c
index 5fdcd7f2e820..dd4e0cb0c6aa 100644
--- a/drivers/pci/tsm.c
+++ b/drivers/pci/tsm.c
@@ -670,7 +670,7 @@ static struct pci_dev *find_dsm_dev(struct pci_dev *pdev)
 		return NULL;
 
 	if (is_dsm(pf0))
-		return pf0;
+		return no_free_ptr(pf0);
 
 	/*
 	 * For cases where a switch may be hosting TDISP services on behalf of
-- 
2.34.1

Re: [PATCH] PCI/TSM: fix use-after-free in find_dsm_dev()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The patch introduces a `struct pci_dev` reference count leak and creates inconsistent return semantics by using `no_free_ptr(pf0)` to suppress reference cleanup.
--

commit b3a70e32ce3263a0eaca05ff9a117ad34fac7def
Author: Wentao Liang <vulab@iscas.ac.cn>

PCI/TSM: fix use-after-free in find_dsm_dev()

This patch modifies find_dsm_dev() to return no_free_ptr(pf0) when returning
the pf0 pointer. This suppresses the automatic cleanup of the reference 
acquired by pf0_dev_get() and transfers ownership of the reference count
to the caller.

> diff --git a/drivers/pci/tsm.c b/drivers/pci/tsm.c
> index 5fdcd7f2e8207..dd4e0cb0c6aae 100644
> --- a/drivers/pci/tsm.c
> +++ b/drivers/pci/tsm.c
> @@ -670,7 +670,7 @@ static struct pci_dev *find_dsm_dev(struct pci_dev *pdev)
>  		return NULL;
>  
>  	if (is_dsm(pf0))
> -		return pf0;
> +		return no_free_ptr(pf0);

[Severity: High]
Does this change introduce a reference count leak for the struct pci_dev?

The original code returned a borrowed reference to the device, but using
no_free_ptr() suppresses the cleanup and transfers the reference count
ownership to the callers.

Looking at the callers of find_dsm_dev(), such as pci_tsm_init() and
pci_tsm_link_constructor(), they expect an un-refcounted pointer and do
not call pci_dev_put() on the returned device:

drivers/pci/tsm.c:pci_tsm_link_constructor() {
	...
	tsm->dsm_dev = find_dsm_dev(pdev);
	...
}

Since these callers do not appear to manage or release the reference, the
device reference could be permanently leaked, which would prevent the
device from being properly unloaded or hot-unplugged.

Additionally, other return paths in find_dsm_dev() (such as returning pdev
or uport) continue to return borrowed pointers. Does this create
inconsistent return semantics where the caller cannot know if a reference
was taken or not?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260616030243.1661791-1-vulab@iscas.ac.cn?part=1

Re: [PATCH] PCI/TSM: fix use-after-free in find_dsm_dev()

[Lukas Wunner]

On Tue, Jun 16, 2026 at 03:02:43AM +0000, Wentao Liang wrote:
> In find_dsm_dev(), pf0 is obtained via pf0_dev_get() which returns a
> reference-counted pointer.  It is declared with __free(pci_dev_put),
> so pci_dev_put() will be called when the variable goes out of scope.
> Returning 'pf0' directly while it still has __free cleanup causes the
> reference to be dropped before the caller can use the pointer, leading
> to a use-after-free.

No, the code comment preceding find_dsm_dev() explicitly states:

   "Note that no additional reference is held for the resulting device
    because that resulting object always has a registered lifetime
    greater-than-or-equal to that of the @pdev argument."

Your patch looks like it may be an LLM-generated hallucination.
Did you use an LLM to come up with the patch?  If so, please use
an Assisted-by tag per Documentation/process/coding-assistants.rst
so that we know to expect hallucinations.

Thanks,

Lukas