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-----