From: sashiko-bot@kernel.org
To: "Nirmal Patel" <nirmal.patel@linux.intel.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH v7] PCI: vmd: Add feature to scan BIOS enumerated devices.
Date: Mon, 29 Jun 2026 17:01:41 +0000 [thread overview]
Message-ID: <20260629170142.9879B1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260629165025.268836-1-nirmal.patel@linux.intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unvalidated BAR 4 length could lead to an out-of-bounds read when accessing shadow registers.
--
commit 7affe7834934181c54062f23e6c8641c3fb30366
Author: Nirmal Patel <nirmal.patel@linux.intel.com>
PCI: vmd: Add feature to scan BIOS enumerated devices.
This commit adds support for newer VMD devices (ID 0x28c1) that rely on
the BIOS to enumerate the device tree and configure settings. It retrieves
the bus hide range and shadow register values from the VMD MMIO space in
BAR4/BAR5 and uses them to perform a bus scan.
> diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
> index d4ae250d4bc6d..a02f2cc3d6ede 100644
> --- a/drivers/pci/controller/vmd.c
> +++ b/drivers/pci/controller/vmd.c
[ ... ]
> @@ -661,6 +706,46 @@ static int vmd_get_bus_number_start(struct vmd_dev *vmd)
> return 0;
> }
>
> +static int vmd_get_bus_info_from_bar4(struct vmd_dev *vmd,
> + resource_size_t *offset1,
> + resource_size_t *offset2)
> +{
> + u64 phys1, phys2, bar4_2840;
> + void __iomem *bar4;
> + u32 base_id;
> + u8 base_bus;
> +
> + bar4 = pci_ioremap_bar(vmd->dev, 4);
> + if (!bar4)
> + return -ENOMEM;
> +
> + /* Read shadow registers for MEMBAR1 and MEMBAR2 physical addresses. */
> + phys1 = readq(bar4 + SHADOW_MEMBAR1_28C1);
[Severity: High]
Can this cause an out-of-bounds read if the resource size of BAR 4 is
smaller than the SHADOW_MEMBAR1_28C1 offset?
If a malicious PCIe device (for example, connected via Thunderbolt) spoofs
the VMD device ID but presents a malformed, small BAR 4 (e.g., 4 KB),
pci_ioremap_bar() will only map the smaller size. The readq() call here
would then access unmapped memory, which could trigger a kernel panic via
a page fault in kernel mode.
Is there a way to validate the length of the BAR 4 resource against
the expected offsets before accessing these shadow registers?
> + phys2 = readq(bar4 + SHADOW_MEMBAR2_28C1);
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260629165025.268836-1-nirmal.patel@linux.intel.com?part=1
prev parent reply other threads:[~2026-06-29 17:01 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-29 16:50 [PATCH v7] PCI: vmd: Add feature to scan BIOS enumerated devices Nirmal Patel
2026-06-29 17:01 ` 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=20260629170142.9879B1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=nirmal.patel@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox