Re: [PATCH v2 1/3] PCI/IOV: Remember initial VF BAR sizes

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

Pre-existing issues:
- [High] Out-of-bounds stack read when processing a 64-bit BAR at the final=
 index.
- [High] Double multiplication of VF BAR size and incorrect per-VF size rec=
ording when initialized via Enhanced Allocation (EA).
--

--- Patch [1]: [PATCH v2 1/3] PCI/IOV: Remember initial VF BAR sizes ---
commit 267f03df0eb1d945e4b2134aa0c449cf8ddfcfca
Author: Marcin Bernatowicz <[email protected]>

PCI/IOV: Remember initial VF BAR sizes

SR-IOV initialization records the per-VF BAR sizes derived from the VF
BAR registers in the SR-IOV capability.

PF drivers may later change VF BAR sizes using VF Resizable BAR support
(pci_iov_vf_bar_set_size()). Save the initial per-VF BAR sizes so later
code can restore them when SR-IOV is disabled, when SR-IOV enable fails,
or when the PF driver is unbound while VF BARs are still resized.

The initial size is captured before the resource is multiplied by
TotalVFs, so it represents one VF's BAR size as advertised by hardware.

No functional change on its own.

> diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
> index b0d24839c0840..ae9309fc6dd73 100644
> --- a/drivers/pci/iov.c
> +++ b/drivers/pci/iov.c
> @@ -869,6 +869,7 @@ static int sriov_init(struct pci_dev *dev, int pos)
>  			goto failed;
>  		}
>  		iov->barsz[i] =3D resource_size(res);

[Severity: High]
This is a pre-existing issue, but does this handle Enhanced Allocation (EA)
initialized devices correctly?

If a device is initialized via EA in pci_ea_init(), the VF BAR resources are
initialized with a total size encompassing all VFs and marked with
IORESOURCE_PCI_FIXED.

Because they are fixed, __pci_read_base() is skipped earlier in the loop,
and resource_size(res) returns the total size instead of a single VF's size.

This results in iov->barsz[i] (and now iov->barsz_orig[i]) incorrectly savi=
ng
the total size, and the resource_set_size() call below multiplying the
already-total size by the number of VFs again, leading to exponential
inflation of requested resource sizes.

Can this cause resource allocation failures for EA-initialized devices?

> +		iov->barsz_orig[i] =3D iov->barsz[i];
>  		resource_set_size(res, resource_size(res) * total);
>  		pci_info(dev, "%s %pR: contains BAR %d for %d VFs\n",
>  			 res_name, res, i, total);

[Severity: High]
This isn't a bug introduced by this patch, but can this loop trigger an
out-of-bounds stack read if a 64-bit BAR is advertised at the final index
(BAR 5)?

Just above this diff hunk in sriov_init(), if the resource is not fixed,
__pci_read_base() is called:

	bar64 =3D __pci_read_base(dev, pci_bar_unknown, res,
				pos + PCI_SRIOV_BAR + i * 4,
				&sriovbars[i]);

sriovbars is a 6-element stack array. If i =3D 5 (the last BAR), &sriovbars=
[5]
is a pointer to the final element.

If the hardware advertises a 64-bit BAR, __pci_read_base() in
drivers/pci/probe.c processes it by reading from index 1:

	if (res->flags & IORESOURCE_MEM_64) {
		pci_read_config_dword(dev, pos + 4, &l);
		sz =3D sizes[1];

Since sizes points to the final element of the sriovbars array, sizes[1]
accesses memory past the end of the stack array. Could a malicious or
malfunctioning hot-plugged PCIe device trigger a KASAN panic here?

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260803103007.2096=
[email protected]?part=3D1