Re: [PATCH v3 6/9] dmaengine: dw-edma: Clear stale requests on termination

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The PCIe driver fails to validate that the PCI BAR size is large enough to contain the hardcoded offsets and sizes for the DMA linked-list and data regions. A malicious PCIe device can present an artificially small BAR, causing the computed iomem pointers to fall outside the mapped region.
--

--- Patch [6]: [PATCH v3 6/9] dmaengine: dw-edma: Clear stale requests on termination ---
commit c7a703de13f7d742a92f8673efc6a54e5f2e9c63
Author: Koichiro Den <den@valinux.co.jp>

dmaengine: dw-edma: Clear stale requests on termination

This commit fixes a stale request issue where a pending PAUSE request
could survive paths that deconfigure a channel. It ensures that the
request state is cleared whenever termination leaves the channel
deconfigured.

> diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c
> index 8b0e2af734da9..2369b4c4630b9 100644
> --- a/drivers/dma/dw-edma/dw-edma-core.c
> +++ b/drivers/dma/dw-edma/dw-edma-core.c

[ ... ]

[Severity: High]
This is a pre-existing issue and was not introduced by this patch, but does
dw_edma_pcie_probe() lack validation against the actual PCI BAR length
before computing I/O memory pointers?

Looking at dw_edma_pcie_probe() in drivers/dma/dw-edma/dw-edma-pcie.c:

drivers/dma/dw-edma/dw-edma-pcie.c:dw_edma_pcie_probe() {
[ ... ]
	for (i = 0; i < chip->ll_wr_cnt && !non_ll; i++) {
		struct dw_edma_region *ll_region = &chip->ll_region_wr[i];
		struct dw_edma_region *dt_region = &chip->dt_region_wr[i];
		struct dw_edma_block *ll_block = &vsec_data->ll_wr[i];
		struct dw_edma_block *dt_block = &vsec_data->dt_wr[i];

		ll_region->vaddr.io = pcim_iomap_table(pdev)[ll_block->bar];
		if (!ll_region->vaddr.io)
			return -ENOMEM;

		ll_region->vaddr.io += ll_block->off;
		ll_region->paddr = dw_edma_get_phys_addr(pdev, vsec_data,
							 ll_block->bar);
		ll_region->paddr += ll_block->off;
		ll_region->sz = ll_block->sz;
[ ... ]
}

If a malicious PCIe or Thunderbolt device presents a spoofed vendor/device
ID with an artificially small BAR, couldn't the computed iomem pointers
fall outside the mapped region?

Should the driver verify that the hardcoded offsets and sizes fit within
the BAR by checking if ll_block->off + ll_block->sz <=
pci_resource_len(pdev, ll_block->bar) prior to pointer arithmetic?

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