From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 148E833262F; Thu, 16 Apr 2026 22:42:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776379360; cv=none; b=VXHv2R3EHZvufCdOX+g2xcYU42q5f1a9kYyw5EjzGgPRuwpZpAheT3BqZLlmjjWYOXRAmQgdwM09ETlTewpxkgNMZCOOKTncBMx7AZepnAgDN3IGKgWROWUHOeOboaFziaXejIwXudm2i8L/csFxbk0nzhs6ekqVzHv1upR9Xu8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776379360; c=relaxed/simple; bh=7Nj+vNpy/vkj8eg2shMUBd4fYul1POhc0Kx6+tca4dg=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition:In-Reply-To; b=MlO1YGNCgJ4rIhfRPG4tvUvLrbbRBsxuULCZljfGKT7S8OwP8p+2wnlxuxdTexum2UxdeJFUJqhwhxsWBM7U8SYOY23piMXBQizGiTVKbaPENZ+kznEx6DR6Xg/5Fqls8DbXXIrAJDUBuxgCA5SDAIP5j3BPTLbCEdj1UwJoREI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=uLds86Cg; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="uLds86Cg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 88605C2BCAF; Thu, 16 Apr 2026 22:42:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776379359; bh=7Nj+vNpy/vkj8eg2shMUBd4fYul1POhc0Kx6+tca4dg=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=uLds86CgS5Y5rcAjyJNrkpZ9/9XG622QV0XIX2b8aIY7YVPowsFIfwdQGbXq+ThGZ sp/CRJCZRvDYYWl1kYgoNil0IHeHnsnOBoc5h1dCAdjxE+iRl+RVpvcrFkIpeak++8 GdtlvbcTs8tn7seSmFMOwWmTtLVdPk5Dv3hU2aKXqhbnE8+6jBZCCml/0TQRnGesxj DuJIwQegIGD5RXjoWcYrtrRzRREwrA2xAmcT8rpGkBJR32rE/FjRErLhoq9cVGaDL3 Lt4nRSvCOPFYk/och0L5YRP3yOmcYWLSpAKJWPeJwdpBG8haGPviMpkfB80Rlbft/6 dbSBzOsSqKsiQ== Date: Thu, 16 Apr 2026 17:42:38 -0500 From: Bjorn Helgaas To: Marco Nenciarini Cc: Bjorn Helgaas , =?utf-8?Q?Micha=C5=82?= Winiarski , Ilpo =?utf-8?B?SsOkcnZpbmVu?= , 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() Message-ID: <20260416224238.GA35669@bhelgaas> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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 > --- > Cc: Michał Winiarski > Cc: Ilpo Järvinen > > 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 >