From: Bjorn Helgaas <helgaas@kernel.org>
To: Marco Nenciarini <mnencia@kcore.it>
Cc: "Bjorn Helgaas" <bhelgaas@google.com>,
"Michał Winiarski" <michal.winiarski@intel.com>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH] PCI/IOV: Fix out-of-bounds access in sriov_restore_vf_rebar_state()
Date: Thu, 16 Apr 2026 17:42:38 -0500 [thread overview]
Message-ID: <20260416224238.GA35669@bhelgaas> (raw)
In-Reply-To: <20260408163922.1740497-1-mnencia@kcore.it>
On Wed, Apr 08, 2026 at 06:39:22PM +0200, Marco Nenciarini wrote:
> sriov_restore_vf_rebar_state() extracts bar_idx from the VF Resizable
> BAR control register using a 3-bit field (PCI_VF_REBAR_CTRL_BAR_IDX,
> bits 0-2), which yields values in the range 0-7. This value is then
> used to index into dev->sriov->barsz[], which has PCI_SRIOV_NUM_BARS
> (6) entries.
>
> If the PCI config space read returns garbage data (e.g. 0xffffffff when
> the device is no longer accessible on the bus), bar_idx is 7, causing
> an out-of-bounds array access. UBSAN reports this as:
>
> UBSAN: array-index-out-of-bounds in drivers/pci/iov.c:948:51
> index 7 is out of range for type 'resource_size_t [6]'
>
> This was observed on an NVIDIA RTX PRO 1000 GPU (GB207GLM) that fell
> off the PCIe bus during a failed GC6 power state exit. The subsequent
> pci_restore_state() call triggered the UBSAN splat in
> sriov_restore_vf_rebar_state() since all config space reads returned
> 0xffffffff.
>
> Add a bounds check on bar_idx before using it as an array index to
> prevent the out-of-bounds access.
I think pci_restore_rebar_state() has a similar problem: if the device
doesn't respond, "nbars" will be 7 (legal values are 1-6), and
"bar_idx" will also be 7 (legal values 0-5). We use "bar_idx" for
pci_resource_n(), and dev->resource[7] does exist but is not a valid
BAR.
> Fixes: 5a8f77e24a30 ("PCI/IOV: Restore VF resizable BAR state after reset")
> Cc: stable@vger.kernel.org
> Signed-off-by: Marco Nenciarini <mnencia@kcore.it>
> ---
> Cc: Michał Winiarski <michal.winiarski@intel.com>
> Cc: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
>
> drivers/pci/iov.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
> index 00784a60b..521f2cb64 100644
> --- a/drivers/pci/iov.c
> +++ b/drivers/pci/iov.c
> @@ -946,6 +946,8 @@ static void sriov_restore_vf_rebar_state(struct pci_dev *dev)
>
> pci_read_config_dword(dev, pos + PCI_VF_REBAR_CTRL, &ctrl);
> bar_idx = FIELD_GET(PCI_VF_REBAR_CTRL_BAR_IDX, ctrl);
> + if (bar_idx >= PCI_SRIOV_NUM_BARS)
> + continue;
Both here and in pci_restore_rebar_state(), we blindly use "nbars"
derived from a value that might be ~0 because the config read failed.
If we fix these, I think we should do something like this so it's
obvious why we're checking:
pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
if (PCI_POSSIBLE_ERROR(ctrl))
return;
nbars = FIELD_GET(PCI_REBAR_CTRL_NBAR_MASK, ctrl);
for (i = 0; i < nbars; ...) {
...
pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
if (PCI_POSSIBLE_ERROR(ctrl))
return;
bar_idx = ctrl & PCI_REBAR_CTRL_BAR_IDX;
res = pci_resource_n(pdev, bar_idx);
It's true that "nbars" and "bar_idx" *could* still be invalid even if
the config read succeeded, but that would be a device defect.
> size = pci_rebar_bytes_to_size(dev->sriov->barsz[bar_idx]);
> ctrl &= ~PCI_VF_REBAR_CTRL_BAR_SIZE;
> ctrl |= FIELD_PREP(PCI_VF_REBAR_CTRL_BAR_SIZE, size);
> --
> 2.47.3
>
next prev parent reply other threads:[~2026-04-16 22:42 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-08 16:39 [PATCH] PCI/IOV: Fix out-of-bounds access in sriov_restore_vf_rebar_state() Marco Nenciarini
2026-04-14 13:01 ` Marco Nenciarini
2026-04-14 13:34 ` Michał Winiarski
2026-04-16 22:42 ` Bjorn Helgaas [this message]
2026-04-16 22:57 ` Bjorn Helgaas
2026-04-17 4:57 ` Lukas Wunner
2026-04-17 13:24 ` [PATCH v2 0/2] PCI: Guard Resizable BAR restore against unreachable devices Marco Nenciarini
2026-04-17 13:24 ` [PATCH v2 1/2] PCI: Skip Resizable BAR restore on read error Marco Nenciarini
2026-04-17 13:24 ` [PATCH v2 2/2] PCI/IOV: Skip VF " Marco Nenciarini
2026-04-24 17:00 ` [PATCH v2 0/2] PCI: Guard Resizable BAR restore against unreachable devices Bjorn Helgaas
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=20260416224238.GA35669@bhelgaas \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=michal.winiarski@intel.com \
--cc=mnencia@kcore.it \
--cc=stable@vger.kernel.org \
/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.