UBUNTU-CVE-2026-72134: High severity ubuntu/linux-hwe-edge vulnerability
In the Linux kernel, the following vulnerability has been resolved: spi: imx: reconfigure for PIO when DMA cannot be started When spiimxcandma() selects DMA, the ECSPI is configured for DMA: spiimxsetupxfer() sets CTRL.SMC and clears dynamicburst, and spiimxdmatransfer() programs the dynamic-burst BURSTLENGTH and the SDMA watermarks. If the DMA descriptor cannot be prepared (dmaengineprepslavesingle() returns NULL), the transfer is failed with SPITRANSFAILNOSTART and falls back to PIO. The dynamic-burst DMA path uses its own bounce buffers instead of the SPI core's mapping, so xfer->{tx,rx}sgmapped are not set and the core's DMA->PIO retry is skipped; the driver falls back to PIO internally. But none of the DMA-mode configuration is undone, so the PIO transfer runs with CTRL.SMC set, the wrong burst length and dynamicburst cleared, and the transferred data is corrupted. This is easily hit on i.MX8MP boards that describe ECSPI DMA in the device tree but run SDMA on ROM firmware (no external sdma-imx7d.bin): every ECSPI DMA prepare fails. An Infineon SLB9670 TPM on ECSPI1 then returns shifted TPM2GetCapability data, is flagged "field failure mode", /dev/tpmrm0 is never created. Set controller->fallback before re-running spiimxsetupxfer() so the ECSPI is reconfigured exactly like a normal PIO transfer. With controller->fallback set, spiimxsetupxfer() sees spiimxcandma() return false, so it clears spiimx->usedma and reprograms the controller (clears CTRL.SMC, restores dynamicburst and the PIO burst length). No explicit spiimx->usedma = false is needed: setupxfer() already updates it from the candma() result.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-aws-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1014.14~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fde-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1016.16~24.04.1 - Upgrade
Upgrade
ubuntu/linux-gcp-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1014.14~24.04.1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-38.38~24.04.4 - Upgrade
Upgrade
ubuntu/linux-nvidia-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1024.25~24.04.1 - Upgrade
Upgrade
ubuntu/linux-oracle-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1013.13~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-38.38 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 7.0.0-1016.16 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 7.0.0-1008.9 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1015.15 - Upgrade
Upgrade
ubuntu/linux-nvidia-bosto a version that resolves this vulnerability.Fixed in 7.0.0-2022.23 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1015.15 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1013.13 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1 - Configuration
Set controller->fallback before re-running spi_imx_setupxfer() when DMA descriptor preparation fails, so the controller is reconfigured for PIO; this clears CTRL.SMC, restores dynamic_burst, and restores the PIO burst length.
Linux kernel SPI i.MX ECSPI driver controller->fallback = true
Event History
Frequently Asked Questions
Which systems are most likely to encounter this issue?
Systems using the i.MX ECSPI controller with DMA described in the device tree are affected when DMA cannot be started. The description specifically identifies i.MX8MP boards using SDMA ROM firmware without an external sdma-imx7d.bin firmware file, where ECSPI DMA preparation fails consistently.
What conditions trigger the data corruption?
The driver must select DMA for an ECSPI transfer, then fail to prepare a DMA descriptor, causing an internal fallback to PIO. Because the DMA controller configuration is not undone before that fallback, the PIO transfer can use incorrect settings and corrupt transferred data.
How could this appear in a deployed system?
Devices on the affected ECSPI bus may return corrupted or shifted data. In the described TPM example, an Infineon SLB9670 on ECSPI1 returns shifted TPM2_GetCapability data, enters field failure mode, and affects /dev/tpmrm0.
What can be done if an updated kernel cannot be deployed immediately?
Avoid the failing DMA setup for the affected ECSPI controller, such as by ensuring the SDMA firmware needed for DMA operation is present rather than relying on ROM firmware. This is relevant where ECSPI DMA is enabled in the device tree and DMA descriptor preparation is failing.