CVE-2024-26806

What it actually does

The cadence-qspi driver incorrectly invokes spi_controller_suspend and spi_controller_resume from its runtime PM hooks, causing a mutex deadlock on ctlr->bus_lock_mutex when exec_op paths already hold the lock and when auto-suspend occurs.

Why it matters to the business

Systems using affected Linux kernels with Cadence QSPI controllers can experience sudden freezes or loss of SPI-attached storage and peripherals, resulting in operational downtime until reboot; prevalence in embedded and server Linux distributions increases exposure surface.

How an attack unfolds

A local attacker triggers concurrent SPI memory operations and runtime power management events on a Cadence QSPI device; the resulting call chain acquires the bus lock, calls pm_runtime_resume_and_get which invokes the resume hook that re-acquires the same lock, producing a deadlock that halts the controller.

How to fix it

Update the Linux kernel to a version containing commit 041562ebc4759c9932b59a06527f8753b86da365 or later; rebuild and deploy the updated kernel package across all affected systems; disable runtime PM for the driver as a temporary workaround if immediate patching is not feasible.

How to confirm the fix worked

Verify the running kernel contains commit 041562ebc4759c9932b59a06527f8753b86da365 via git log or package version; confirm absence of the problematic calls in drivers/spi/spi-cadence-quadspi.c; test SPI operations under varying runtime PM states to ensure no deadlock occurs.

Typical attack path

1. Obtain local execution on a Linux system with cadence-qspi enabled hardware
2. Issue SPI memory operations via spi_mem_exec_op while runtime PM usage count changes occur
3. Force or wait for runtime suspend/resume transitions that call the flawed hooks
4. Trigger the nested mutex acquisition leading to deadlock and denial of service

How to detect it

Review kernel logs for mutex deadlock warnings or hung task traces involving spi_controller_resume, cqspi_resume, or bus_lock_mutex; inspect dmesg and /var/log/kern.log around SPI device activity and runtime PM events for Cadence QSPI controllers.

What your security team should do

• Prioritize kernel upgrades to the fixed commit within standard patch windows given low EPSS and absence from KEV
• Audit systems for cadence-qspi usage and apply targeted kernel updates
• Monitor vendor kernel package releases for backports of the fix
• Document the change in runtime PM handling for future driver reviews