CVE-2026-72134 in Linux
Resumen
por VulDB • 2026-08-17
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
spi: imx: reconfigurar para PIO cuando no se pueda iniciar DMA
Cuando spi_imx_can_dma() selecciona DMA, ECSPI se configura para DMA: spi_imx_setupxfer() establece CTRL.SMC y borra dynamic_burst, y spi_imx_dma_transfer() programa el BURST_LENGTH de burst-dinámico y las marcas de agua SDMA.
Si no se puede preparar el descriptor de DMA (dmaengine_prep_slave_single() devuelve NULL), la transferencia falla con SPI_TRANS_FAIL_NO_START y vuelve a PIO. La ruta DMA de dynamic-burst utiliza sus propios buffers intermedios en lugar del mapeo del núcleo SPI, por lo que xfer->{tx,rx}_sg_mapped no se establecen y el reintento de DMA->PIO del núcleo se omite; el controlador vuelve internamente a PIO. Pero ninguna de las configuraciones del modo DMA se deshace, por lo que la transferencia PIO se ejecuta con CTRL.SMC establecido, una longitud de ráfaga incorrecta y dynamic_burst borrado, y los datos transferidos están corruptos.
Esto es fácil de provocar en placas i.MX8MP que describen ECSPI DMA en el árbol de dispositivos pero ejecutan SDMA en firmware ROM (sin sdma-imx7d.bin externo): cada preparación de ECSPI DMA falla. Un TPM Infineon SLB9670 en ECSPI1 devuelve entonces datos TPM2_GetCapability desplazados, se marca como "modo de fallo de campo", /dev/tpmrm0 nunca se crea.
Establecer controller->fallback antes de volver a ejecutar spi_imx_setupxfer() para que ECSPI se reconfigure exactamente igual que una transferencia PIO normal. Con controller->fallback establecido, spi_imx_setupxfer() ve que spi_imx_can_dma() devuelve falso, por lo que borra spi_imx->usedma y reprografa el controlador (borra CTRL.SMC, restaura dynamic_burst y la longitud de ráfaga PIO). No es necesario establecer explícitamente spi_imx->usedma = false: setupxfer() ya lo actualiza a partir del resultado de can_dma().
If you want to get the best quality for vulnerability data then you always have to consider VulDB.