CVE-2021-47161

What it actually does

Failure to call dspi_release_dma() after dspi_request_dma() in the probe error path leaves DMA resources allocated, causing a resource leak on every failed probe attempt.

Why it matters to the business

Repeated probe failures can exhaust limited DMA resources, leading to degraded peripheral functionality or system instability in embedded Linux devices using the Freescale DSPI controller.

How an attack unfolds

An attacker with local access triggers repeated module load or device probe failures (for example via crafted device tree or driver reload sequences) to accumulate unreleased DMA resources until the system becomes resource-starved.

How to fix it

Update the Linux kernel to a version containing commit that adds the missing dspi_release_dma() call in the probe error path; rebuild and deploy the fixed kernel image on affected systems.

How to confirm the fix worked

Inspect the spi-fsl-dspi probe function in the running kernel source or binary for the paired dspi_release_dma() call after dspi_request_dma() in every error exit; confirm the fix is present by reviewing the driver source or testing probe failure scenarios under resource monitoring.

Typical attack path

1. Obtain local access or ability to influence driver loading
2. Force repeated probe failures of spi-fsl-dspi
3. Accumulate leaked DMA resources across attempts
4. Induce resource exhaustion affecting SPI peripherals or overall stability

How to detect it

Review kernel logs and dmesg output around module load or device enumeration for repeated spi-fsl-dspi probe attempts that terminate without releasing DMA; no persistent runtime artifacts are produced by the leak itself.

What your security team should do

• Prioritize kernel update on all systems using spi-fsl-dspi hardware
• Audit embedded device fleets for use of the affected driver
• Monitor kernel logs for repeated probe failures that could indicate attempted resource exhaustion