Re: [PATCH v2 7/7] PCI/quirks: Avoid certain address on Genoa systems

["Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 3111 bytes --]

On Fri, 2 Oct 2026, sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] pci/quirks: skipped workaround and UAF on rescan due to dangling resource pointer
> --
> 
> commit 988b9fe1c0d1202ac7629ed0f5250a0381f61b90
> Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> 
> PCI/quirks: Avoid certain address on Genoa systems
> 
> This commit addresses a 64kB iomem black hole on Genoa systems that causes
> reads to return ~0 and blocks overlapping BARs from working. It reserves the
> problematic space via a bridge quirk.
> 
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=222074
> 
> > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> > index de9bbccda21fd..5483b47d8d544 100644
> > --- a/drivers/pci/quirks.c
> > +++ b/drivers/pci/quirks.c
> 
> [ ... ]
> 
> > +static struct resource black_hole_res = DEFINE_RES_MEM_NAMED(0x9c000000, SZ_64K,
> > +							     "reserved");
> > +
> > +static void genoa_iomem_black_hole(struct pci_dev *dev)
> > +{
> > +	struct resource *r;
> > +
> > +	pci_bus_for_each_resource(dev->bus, r) {
> > +		if (!r || !r->flags || !resource_assigned(r))
> > +			continue;
> > +
> > +		if (!__resource_contains_unbound(r, &black_hole_res))
> > +			continue;
> > +
> > +		if (resource_assigned(&black_hole_res))
> > +			pci_dbg(dev, "iomem black hole workaround already applied\n");
> 
> [Severity: High]
> Can this lead to a use-after-free and cause the workaround to be skipped on
> rescan?
> 
> During the first probe, insert_resource() sets black_hole_res.parent to the
> dynamically allocated host bridge window. If the PCI bridge is subsequently
> removed, the bridge's resources are released and freed.
> 
> However, release_resource() unlinks the parent but does not clear the parent
> pointers of child resources. Because black_hole_res is statically allocated,
> its parent pointer is left dangling.
>
> When the bus is rescanned, resource_assigned(&black_hole_res) evaluates to
> true due to the dangling parent pointer. The code erroneously logs "already
> applied" and skips inserting the reservation into the new bridge window.
>
> This leaves the new window unprotected, allowing subsequent BAR allocations
> to fall into the 0x9c000000 black hole.

Before sending this, I did test removing the PCI devices all the way to 
the Root Complex (RC included) and the black hole marker weathered the 
storm just fine.

I suppose if I'd proceed removing something from further up (something 
ACPI side?), the scenario might actually occur but why would anyone want 
to do that?

I think this goes to the territory where root has many ways to shoot 
oneself's own foot...

-- 
 i.
 
> > +		else if (!insert_resource(r, &black_hole_res))
> > +			pci_info(dev, "iomem black hole workaround enabled\n");
> > +		else
> > +			pci_dbg(dev, "iomem black hole workaround add failed\n");
> > +		return;
> > +	}
> > +}
> > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AMD, 0x14ab, genoa_iomem_black_hole);
> 
>