All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Wentao Liang" <vulab@iscas.ac.cn>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH] PCI/TSM: fix use-after-free in find_dsm_dev()
Date: Tue, 16 Jun 2026 03:11:08 +0000	[thread overview]
Message-ID: <20260616031109.501921F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260616030243.1661791-1-vulab@iscas.ac.cn>

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

  reply	other threads:[~2026-06-16  3:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-16  3:02 [PATCH] PCI/TSM: fix use-after-free in find_dsm_dev() Wentao Liang
2026-06-16  3:11 ` sashiko-bot [this message]
2026-06-16  3:16 ` Lukas Wunner

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=20260616031109.501921F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vulab@iscas.ac.cn \
    /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.