All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Rihyeon Kim" <rihyeon8648@gmail.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH v2 2/2] PCI: Free the device name on the pci_setup_device() error path
Date: Sun, 26 Jul 2026 09:43:39 +0000	[thread overview]
Message-ID: <20260726094340.087C31F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260726093200.146111-3-rihyeon8648@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Memory allocated by early fixups (e.g., `dev->saved_cap_space` and `dev->dma_alias_mask`) is leaked when `pci_setup_device()` encounters an unknown header type.
--

--- Patch [2]: [PATCH v2 2/2] PCI: Free the device name on the pci_setup_device() error path ---
commit 25426f7c4f229419785305695a130234f0fdabc2
Author: Rihyeon Kim <rihyeon8648@gmail.com>

PCI: Free the device name on the pci_setup_device() error path
    
This commit frees the device name in the pci_setup_device() error path
for unknown header types. Since device_initialize() hasn't been called,
pci_scan_device() simply uses kfree() to release the device, which
previously leaked the allocated name.

Link: https://lore.kernel.org/linux-pci/20220817084444.2876059-1-yangyingliang@huawei.com/

> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 3e6f0eb7d456c..74d84093943bb 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -2192,6 +2192,8 @@ int pci_setup_device(struct pci_dev *dev)
>  	default:				    /* unknown header */
>  		pci_err(dev, "unknown header type %02x, ignoring device\n",
>  			dev->hdr_type);
> +		kfree_const(dev->dev.kobj.name);
> +		dev->dev.kobj.name = NULL;
>  		pci_release_of_node(dev);
 
[Severity: High]
This isn't a bug introduced by this patch, but since we're fixing leaks on
this exact error path, does this also leak memory allocated by early fixups?

Earlier in pci_setup_device(), we execute:

    pci_fixup_device(pci_fixup_early, dev);

Some of these early fixups dynamically allocate memory and attach it to the
device structure. For example, quirk_intel_qat_vf_cap() allocates state
buffers:

drivers/pci/quirks.c:quirk_intel_qat_vf_cap() {
    ...
    state = kzalloc(sizeof(*state) + size, GFP_KERNEL);
    ...
    pci_add_saved_cap(pdev, state);
}

Similarly, pci_add_dma_alias() allocates a bitmap:

drivers/pci/pci.c:pci_add_dma_alias() {
    ...
    dev->dma_alias_mask = bitmap_zalloc(MAX_NR_DEVFNS, GFP_KERNEL);
    ...
}

Because pci_scan_device() handles the -EIO return by directly calling
kfree(dev) instead of going through standard device release, it seems these
dynamically allocated resources (dev->saved_cap_space, dev->dma_alias_mask)
will also be permanently leaked here.

>  		return -EIO;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260726093200.146111-1-rihyeon8648@gmail.com?part=2

      reply	other threads:[~2026-07-26  9:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-26  9:31 [PATCH v2 0/2] PCI: Fix dev_set_name() error handling in pci_setup_device() Rihyeon Kim
2026-07-26  9:31 ` [PATCH v2 1/2] PCI: Handle dev_set_name() failure " Rihyeon Kim
2026-07-26  9:49   ` sashiko-bot
2026-07-26  9:32 ` [PATCH v2 2/2] PCI: Free the device name on the pci_setup_device() error path Rihyeon Kim
2026-07-26  9:43   ` 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=20260726094340.087C31F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=rihyeon8648@gmail.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.