From: sashiko-bot@kernel.org
To: "Gary Guo" <gary@garyguo.net>
Cc: linux-scsi@vger.kernel.org, dlemoal@kernel.org,
cassel@kernel.org, linux-pci@vger.kernel.org,
linux-ide@vger.kernel.org
Subject: Re: [PATCH v2 3/7] ipack: tpci200: don't keep pci_device_id
Date: Wed, 01 Jul 2026 11:10:43 +0000 [thread overview]
Message-ID: <20260701111044.3DD291F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260630-pci_id_fix-v2-3-b834a98c0af2@garyguo.net>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] MMIO registers are accessed before the PCI device is enabled.
--
commit 30f524f5c4f44d8d3fe4dc97ba1c44684c0fe834
Author: Gary Guo <gary@garyguo.net>
ipack: tpci200: don't keep pci_device_id
This commit removes the unused pci_device_id table from the tpci200_infos
structure. The stored ID is unnecessary as dynamic IDs may not outlive
the probe function.
> diff --git a/drivers/ipack/carriers/tpci200.c b/drivers/ipack/carriers/tpci200.c
> index 05dcb6675cd66..1cf51f7632932 100644
> --- a/drivers/ipack/carriers/tpci200.c
> +++ b/drivers/ipack/carriers/tpci200.c
> @@ -562,7 +562,6 @@ static int tpci200_pci_probe(struct pci_dev *pdev,
>
> /* Save struct pci_dev pointer */
[Severity: High]
This is a pre-existing issue, but does this probe function access
memory-mapped configuration registers before the PCI device is enabled?
Looking at tpci200_pci_probe() in drivers/ipack/carriers/tpci200.c,
we can see MMIO accesses happening just before this block:
drivers/ipack/carriers/tpci200.c:tpci200_pci_probe() {
...
reg32 = ioread32(tpci200->info->cfg_regs + LAS1_DESC);
reg32 |= 1 << LAS_BIT_BIGENDIAN;
iowrite32(reg32, tpci200->info->cfg_regs + LAS1_DESC);
...
}
Since pci_enable_device() is not called until later down the call chain
in tpci200_register() (called via tpci200_install()), PCI_COMMAND_MEMORY
may not be set.
This can result in ignored writes, reading junk data (all 1s), and on
many architectures, it triggers a machine check exception, SError, or
kernel panic due to an Unsupported Request (UR) on the PCIe bus.
> tpci200->info->pdev = pdev;
> - tpci200->info->id_table = (struct pci_device_id *)id;
>
> /* register the device and initialize it */
> ret = tpci200_install(tpci200);
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260630-pci_id_fix-v2-0-b834a98c0af2@garyguo.net?part=3
next prev parent reply other threads:[~2026-07-01 11:10 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-30 11:09 [PATCH v2 0/7] pci: fix UAF and TOCTOU related to dynamic ID Gary Guo
2026-06-30 11:09 ` [PATCH v2 1/7] ata: don't keep pci_device_id Gary Guo
2026-06-30 11:59 ` Niklas Cassel
2026-06-30 12:41 ` Gary Guo
2026-06-30 19:46 ` Danilo Krummrich
2026-07-01 11:10 ` sashiko-bot
2026-06-30 11:09 ` [PATCH v2 2/7] nsp32: " Gary Guo
2026-06-30 19:46 ` Danilo Krummrich
2026-07-01 11:10 ` sashiko-bot
2026-06-30 11:09 ` [PATCH v2 3/7] ipack: tpci200: " Gary Guo
2026-06-30 19:47 ` Danilo Krummrich
2026-07-01 11:10 ` sashiko-bot [this message]
2026-06-30 11:09 ` [PATCH v2 4/7] mlxsw: " Gary Guo
2026-06-30 19:48 ` Danilo Krummrich
2026-07-01 11:10 ` sashiko-bot
2026-07-01 13:57 ` Petr Machata
2026-06-30 11:09 ` [PATCH v2 5/7] pci: make pci_match_one_device match on ID instead of device Gary Guo
2026-06-30 20:04 ` Danilo Krummrich
2026-07-01 11:10 ` sashiko-bot
2026-06-30 11:09 ` [PATCH v2 6/7] pci: fix dyn_id add TOCTOU Gary Guo
2026-06-30 20:16 ` Danilo Krummrich
2026-07-01 11:10 ` sashiko-bot
2026-06-30 11:09 ` [PATCH v2 7/7] pci: fix UAF when probe runs concurrent to dyn ID removal Gary Guo
2026-06-30 20:25 ` Danilo Krummrich
2026-07-01 11:10 ` sashiko-bot
2026-07-01 11:44 ` Gary Guo
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=20260701111044.3DD291F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=cassel@kernel.org \
--cc=dlemoal@kernel.org \
--cc=gary@garyguo.net \
--cc=linux-ide@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-scsi@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 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.