Linux Kernel up to 7.1.4 SPI Driver spi_imx_setupxfer fallback input validation

Summaryinfo

A vulnerability has been found in Linux Kernel up to 7.1.4 and classified as very critical. This vulnerability affects the function spi_imx_setupxfer of the component SPI Driver. This manipulation of the argument fallback causes input validation. This vulnerability is tracked as CVE-2026-72134. The attack is restricted to local execution. No exploit exists.

Detailsinfo

A vulnerability classified as very critical was found in Linux Kernel up to 7.1.4. Affected by this vulnerability is the function spi_imx_setupxfer of the component SPI Driver. The manipulation of the argument fallback with an unknown input leads to a input validation vulnerability. The CWE definition for the vulnerability is CWE-20. The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly. As an impact it is known to affect confidentiality, integrity, and availability. The summary by CVE is:

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.

It is possible to read the advisory at git.kernel.org. This vulnerability is known as CVE-2026-72134 since 08/09/2026. The exploitation appears to be easy. Attacking locally is a requirement. Technical details of the vulnerability are known, but there is no available exploit. The pricing for an exploit might be around USD $0-$5k at the moment (estimation calculated on 08/15/2026).

Upgrading to version 7.1.5 or 7.2-rc1 eliminates this vulnerability. Applying the patch 40dee2d3e9994aed9efe7bed40eb0e4d38d5a25c/245404c26563aafb36aafb01298f148db1851be3 is able to eliminate this problem.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 7.1.0
• 7.1.1
• 7.1.2
• 7.1.3
• 7.1.4

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Discussion