Re: [PATCH v2 2/2] arm64: tegra: Enable DMA Support on Tegra194 QSPI

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Calling dma_unmap_single on an unmapped DMA address during the DMA mapping error path.
- [High] DMA buffer overflow causing memory corruption when reading unaligned sizes in packed mode.
--

commit ab48224cb433a33d32049c6cfc39eea2bdf25194
Author: Aaron Kling <webgeek1234@gmail.com>

arm64: tegra: Enable DMA Support on Tegra194 QSPI

Without dma enabled pio mode is used and flash storage such as the one
on the p3668 module times out and cannot complete any transfers. In some
cases, these timeouts cause hangs and cbb faults.

> diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> index 1d659454a6f9f..e2ddbc6715d5e 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> @@ -923,6 +923,8 @@ spi@3270000 {
>  				 <&bpmp TEGRA194_CLK_QSPI0_PM>;
>  			clock-names = "qspi", "qspi_out";
>  			resets = <&bpmp TEGRA194_RESET_QSPI0>;
> +			dmas = <&gpcdma 5>, <&gpcdma 5>;
> +			dma-names = "rx", "tx";

[Severity: High]
This isn't a bug introduced by this patch, but enabling DMA mode exposes a
pre-existing issue in the driver.

In tegra_qspi_dma_map_xfer(), t->tx_dma is mapped conditionally only if
t->tx_buf is non-NULL.

However, if mapping t->rx_buf subsequently fails, the error path
unconditionally calls dma_unmap_single(..., t->tx_dma, ...).

If t->tx_buf was NULL, t->tx_dma is zero or uninitialized.

Could this lead to unmapping an invalid DMA address, potentially corrupting
IOMMU page tables or triggering a panic?

[Severity: High]
This is a pre-existing issue, but directly switching the controller to
DMA mode makes a buffer overflow vulnerability triggerable.

In tegra_qspi_start_dma_based_transfer(), the driver calculates the mapped
and transferred DMA length by rounding up to the nearest multiple of 4:
len = DIV_ROUND_UP(..., 4) * 4.

For an unaligned SPI read (e.g., 5 bytes), len becomes 8. The driver maps 8
bytes and programs the DMA engine to write exactly 8 bytes into the client's
t->rx_buf via dmaengine_prep_slave_single().

Because the client's t->rx_buf is only guaranteed to be the requested 5 bytes
long, does this cause the DMA hardware to blindly overwrite adjacent memory
by 3 bytes?

Could this out-of-bounds write corrupt adjacent heap objects or KASAN
redzones?

>  			status = "disabled";
>  		};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260525-tegra194-qspi-iommu-v2-0-a11c53f804b2@gmail.com?part=2