From: sashiko-bot@kernel.org
To: "Ma Ke" <make_ruc2021@163.com>
Cc: linux-usb@vger.kernel.org
Subject: Re: [PATCH v2] usb: cdns3: Fix PCI device reference leak in cdns3_pci_probe()
Date: Mon, 12 Oct 2026 07:11:32 +0000 [thread overview]
Message-ID: <sashiko-outbox-167779@kernel.org> (raw)
In-Reply-To: <20261012070310.3704130-1-make_ruc2021@163.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] usb: cdns3: UAF in cdns3_pci_probe() error path freeing shared drvdata
--
commit 4c0bd2a76b0d6740fa24b374ecb3e7b1b96c27ce
Author: Ma Ke <make_ruc2021@163.com>
usb: cdns3: Fix PCI device reference leak in cdns3_pci_probe()
This commit addresses a PCI device reference leak in the cdns3 driver by
ensuring pci_dev_put() is called on the device returned by
cdns3_get_second_fun(). It updates the probe and remove functions to
properly release the reference, including in error paths. A missing NULL
check before pci_is_enabled() in the remove function is also added.
> diff --git a/drivers/usb/cdns3/cdns3-pci-wrap.c b/drivers/usb/cdns3/cdns3-pci-wrap.c
> index fd06a3d8e638f..7799349bba771 100644
> --- a/drivers/usb/cdns3/cdns3-pci-wrap.c
> +++ b/drivers/usb/cdns3/cdns3-pci-wrap.c
[ ... ]
> @@ -165,11 +168,13 @@ static int cdns3_pci_probe(struct pci_dev *pdev,
> if (IS_ERR(wrap->plat_dev)) {
> err = PTR_ERR(wrap->plat_dev);
> kfree(wrap);
> - return err;
> + goto put_pci;
> }
> }
[Severity: High]
Can this error path free a shared drvdata object?
When pci_is_enabled(func) is true, wrap is retrieved from the sibling
function's drvdata:
cdns3_pci_probe() {
...
if (pci_is_enabled(func)) {
wrap = pci_get_drvdata(func);
...
}
If platform_device_register_full() fails later in the probe function, the
error path unconditionally calls kfree(wrap).
Because the sibling function still holds a pointer to this wrap object in
its drvdata, freeing it here can cause a use-after-free and potential
double-free when the sibling function is subsequently removed or accessed
(for example, when cdns3_pci_remove() dereferences wrap->devfn).
Should kfree(wrap) be skipped here if wrap was retrieved from the sibling
function rather than allocated in this probe call?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261012070310.3704130-1-make_ruc2021@163.com?part=1
prev parent reply other threads:[~2026-10-12 7:11 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 7:03 [PATCH v2] usb: cdns3: Fix PCI device reference leak in cdns3_pci_probe() Ma Ke
2026-10-12 7:11 ` sashiko-bot [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=sashiko-outbox-167779@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=make_ruc2021@163.com \
--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.