Re: [PATCH v8 4/6] PCI: tegra: Add Tegra264 support

Thierry Reding <[email protected]>
Newsgroups dev.linux.lists.sashiko-reviews,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-pci
Message-ID <ameNj2Gh8mgqL7kB@orome>
On Thu, Jul 16, 2026 at 05:19:46PM +0000, [email protected] wrote:
[...]
> > +	}
> > +
> > +	/* sanity check that programmed ranges match what's in DT */
> > +	if (!tegra264_pcie_check_ranges(pdev)) {
> > +		err = -EINVAL;
> > +		goto err_put_pm;
> > +	}
> > +
> > +	pcie->cfg = pci_ecam_create(dev, res, bus->res, &pci_generic_ecam_ops);
> > +	if (IS_ERR(pcie->cfg)) {
> > +		err = dev_err_probe(dev, PTR_ERR(pcie->cfg),
> > +				    "failed to create ECAM\n");
> > +		goto err_put_pm;
> > +	}
> > +
> > +	bridge->ops = (struct pci_ops *)&pci_generic_ecam_ops.pci_ops;
> > +	bridge->sysdata = pcie->cfg;
> > +	pcie->ecam = pcie->cfg->win;
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> [Severity: High]
> Can this assignment cause an out-of-bounds heap read on 32-bit platforms?
> 
> If the driver is compiled on a 32-bit architecture (e.g. via COMPILE_TEST)
> where per_bus_mapping is true, the pci_config_window->win union aliases the
> dynamically allocated cfg->winp array pointer.
> 
> When the driver later dereferences pcie->ecam using readw() in
> tegra264_pcie_link_up():
> 
>     u16 value = readw(pcie->ecam + XTL_RC_PCIE_CFG_LINK_STATUS);
> 
> It will read from the heap array pointer instead of mapped I/O memory,
> resulting in a crash or garbage read.

For the record: no I don't think this is ever going to happen. Yes, if
you build the driver on 32-bit ARM it might generate code that is wrong,
but that code will also never run because Tegra264 is only 64-bit ARM.

Thierry
signature.asc (application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmpnjgUACgkQ3SOs138+
s6HceQ/9Hgi0ouKCuPVhDZwnsqoCrczbLoQxK2GI05yJ5XMT95Mi0fhsWcBQmGKd
BUJM5baIRhP0cnfBOJu7VddYgMZIfMcJ4p23Q3LBpBuv6OSvHbPDVNtB4Ddp89Dl
VfPvrAk1bBtM3K+MF0jLG/YGGlFMSSU0tI8tGgg0smORP0oaVB7p64WVpVrrM4bo
G3Vh+0PeqeKXIShuy7RKRuFPVs9MLGRScWbYFJWDvRahwXsGiZ6gixD/tmF3mVAA
Bi/QnIQnpbSXBewkmfjtSZVb73+3MvJVpEl/B56uqaJ8FJ0i0Diym7XBuxnTzOmt
cDpkOWanyY+9VJUNqd0wI0OZDqmR8U69LZZKFgOuc2o4Mb2CzfhpTQuZUa/jRVGx
tFweNsLQkLcskDcWbz2GPN80Bnu1sNXhIZjI70W6C1uUKY+wEoBVWP+mGvFGL5T5
CCKG14fsdjT5b9rzOAn+EFLIy5f7b6o+RYFNLR6oWBnN6M5ercXYqEKThiFnjGfY
Zu96Ivw1cTaPxW1OhoxbdC2jGJNw39hbuMl0Cg2StaPOWruskdgARMVj09sHkgnz
QdH1p+kSUl4UBVo9gmnkBB+QHx2Zr8QIi39LZYx74cOF/afkHOb1nZVfJ7bJXA49
ik85BUSKrgB0V4Be/WJsBgq5pfa2hvUbrW6TLwa5c+Nh4qsVzqk=
=XNy/
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.