CVE-2026-72134 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
spi: imx: reconfigure for PIO when DMA cannot be started
When spi_imx_can_dma() selects DMA, the ECSPI is configured for DMA: spi_imx_setupxfer() sets CTRL.SMC and clears dynamic_burst, and spi_imx_dma_transfer() programs the dynamic-burst BURST_LENGTH and the SDMA watermarks.
If the DMA descriptor cannot be prepared (dmaengine_prep_slave_single() returns NULL), the transfer is failed with SPI_TRANS_FAIL_NO_START 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}_sg_mapped
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 dynamic_burst 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 TPM2_GetCapability data, is flagged "field failure mode", /dev/tpmrm0 is never created.
Set controller->fallback before re-running spi_imx_setupxfer() so the ECSPI is reconfigured exactly like a normal PIO transfer. With controller->fallback set, spi_imx_setupxfer() sees spi_imx_can_dma() return false, so it clears spi_imx->usedma and reprograms the controller (clears CTRL.SMC, restores dynamic_burst and the PIO burst length). No explicit spi_imx->usedma = false is needed: setupxfer() already updates it from the can_dma() result.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/16/2026
The Linux kernel SPI driver for i.MX platforms contains a critical configuration state management flaw that leads to data corruption when falling back from Direct Memory Access mode to Programmed I/O mode. This vulnerability arises in the spi_imx driver, specifically within the logic handling DMA preparation failures. The ECSPI controller supports both DMA and PIO transfer methods, with the driver attempting to optimize performance by selecting DMA whenever possible through the spi_imx_can_dma function. When this selection succeeds, the hardware is configured for DMA operation by setting specific control register bits such as CTRL.SMC and clearing dynamic_burst flags. Additionally, the SDMA watermarks and burst lengths are programmed via dmaengine_prep_slave_single calls to prepare descriptors for data movement.
The core issue manifests when the system fails to allocate or prepare a valid DMA descriptor, causing dmaengine_prep_slave_single to return NULL. In this scenario, the transfer is initially marked as failed with SPI_TRANS_FAIL_NO_START, triggering an internal fallback mechanism intended to retry the operation using PIO instead of DMA. However, the driver logic contains a defect where it does not properly reset the hardware configuration before re-executing the setup routine for the PIO path. Consequently, while the software state transitions to PIO mode internally, the ECSPI controller remains configured with settings specific to DMA operations. Specifically, CTRL.SMC remains set, dynamic_burst stays cleared, and incorrect burst length parameters persist in the control registers.
This mismatch between the driver's internal state and the actual hardware configuration results in severe data corruption during subsequent transfers executed via PIO. The transferred data is shifted or garbled because the controller interprets the incoming bitstream according to DMA-specific timing and framing rules rather than standard PIO expectations. This issue is particularly prevalent on i.MX8MP boards where device tree descriptions indicate ECSPI support for DMA, but the system relies on SDMA firmware loaded from ROM without external binaries like sdma-imx7d.bin. In such environments, every attempt to prepare a DMA descriptor fails due to missing firmware resources, forcing repeated fallbacks that leave the hardware in an incorrect state.
The operational impact of this vulnerability is significant for systems relying on SPI-connected peripherals sensitive to data integrity. A documented real-world consequence involves Infineon SLB9670 Trusted Platform Modules connected via ECSPI1. Due to the corrupted data transmission caused by the misconfigured controller, these TPMs return shifted responses to commands such as TPM2_GetCapability. The hardware interprets this malformed input as a critical error, entering field failure mode and preventing the creation of the /dev/tpmrm0 interface. This effectively disables remote attestation capabilities and compromises security features dependent on reliable SPI communication with the TPM.
To resolve this vulnerability, the driver must explicitly signal to the setup routine that it is operating in fallback mode before re-invoking spi_imx_setupxfer. By setting controller->fallback prior to the retry, the can_dma check within the setup function correctly returns false. This forces the driver to clear the usedma flag and reprogram the ECSPI control registers with appropriate PIO settings, including clearing CTRL.SMC and restoring dynamic_burst along with correct burst lengths. This ensures that the hardware configuration aligns perfectly with the selected transfer method, eliminating data corruption risks during fallback scenarios.
From a vulnerability classification perspective, this defect corresponds to CWE-672, which involves the use of operation-specific variables without proper validation or initialization before reuse in different contexts. The failure to reset hardware state after an error condition represents a lack of proper resource cleanup and state synchronization between software logic and peripheral registers. In terms of attack vectors, while primarily causing denial of service through functional degradation rather than direct exploitation for privilege escalation, it aligns with ATT&CK techniques related to disruption of availability by manipulating system resources or configurations. Mitigation requires applying the kernel patch that implements the fallback flag check before reconfiguration, ensuring robust state management across transfer mode transitions.