Re: [PATCH v2 10/15] PCI: rcar-gen4: Take over the iMSI-RX interrupt

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] PCI: rcar-gen4: UAF in MSI IRQ domain due to early freeing in teardown
--

commit af654bd32d2cbf225a560670eb31511987c35382
Author: Koichiro Den <den@valinux.co.jp>

PCI: rcar-gen4: Take over the iMSI-RX interrupt

This patch requests the "msi" interrupt in the driver and demultiplexes
the MSIs to handle controller reset requests and Root Port notifications
on the same line. The driver takes ownership of the interrupt instead of
the DesignWare core.

> diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> index d3f04358bbe31..256410fb4b1cd 100644
> --- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> +++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c

[ ... ]

> @@ -818,6 +878,9 @@ static void rcar_gen4_pcie_host_deinit(struct dw_pcie_rp *pp)
>  	struct dw_pcie *dw = to_dw_pcie_from_pp(pp);
>  	struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
>  
> +	/* Stop the handler before asserting reset and disabling the clocks. */
> +	free_irq(rcar->msi_irq, rcar);
> +

[Severity: High]
Does this setup introduce a use-after-free risk during teardown?

During driver removal or probe failure, dw_pcie_host_deinit() calls
dw_pcie_free_msi() to free the MSI IRQ domain before it calls the driver's
.deinit callback:

drivers/pci/controller/dwc/pcie-designware-host.c:dw_pcie_host_deinit() {
	...
	if (pp->use_imsi_rx)
		dw_pcie_free_msi(pp);

	if (pp->ops->deinit)
		pp->ops->deinit(pp);
	...
}

Because pp->msi_irq[0] is set to -ENODEV, the DWC core does not unhook any
handler. This means rcar_gen4_pcie_msi_irq_handler() remains active and
could execute before free_irq() is called in rcar_gen4_pcie_host_deinit().

If an MSI is latched just before the link is stopped, the active handler
will dispatch to the DWC core via dw_handle_msi_irq(&rcar->dw.pp) and
dereference the freed pp->irq_domain.

While the commit message acknowledges this as a gap that might require a
common DWC core fix, this patch actively introduces a crash path for this
driver that could be triggered reliably on driver unbind or probe error
with pending MSIs.

Could we synchronize or stop the handler earlier to prevent this dereference?

>  	rcar_gen4_pcie_host_perst_assert(pp, true);
>  	rcar->drvdata->deinit(rcar);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260928165230.3397664-1-den@valinux.co.jp?part=10