CVE-2024-26806 in Linux
Summary
by MITRE • 04/04/2024
In the Linux kernel, the following vulnerability has been resolved:
spi: cadence-qspi: remove system-wide suspend helper calls from runtime PM hooks
The ->runtime_suspend() and ->runtime_resume() callbacks are not expected to call spi_controller_suspend() and spi_controller_resume(). Remove calls to those in the cadence-qspi driver.
Those helpers have two roles currently: - They stop/start the queue, including dealing with the kworker. - They toggle the SPI controller SPI_CONTROLLER_SUSPENDED flag. It requires acquiring ctlr->bus_lock_mutex.
Step one is irrelevant because cadence-qspi is not queued. Step two however has two implications: - A deadlock occurs, because ->runtime_resume() is called in a context where the lock is already taken (in the ->exec_op() callback, where the usage count is incremented). - It would disallow all operations once the device is auto-suspended.
Here is a brief call tree highlighting the mutex deadlock:
spi_mem_exec_op() ... spi_mem_access_start() mutex_lock(&ctlr->bus_lock_mutex)
cqspi_exec_mem_op() pm_runtime_resume_and_get() cqspi_resume() spi_controller_resume() mutex_lock(&ctlr->bus_lock_mutex) ...
spi_mem_access_end() mutex_unlock(&ctlr->bus_lock_mutex) ...
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/04/2025
The vulnerability CVE-2024-26806 affects the Linux kernel's cadence-qspi driver and represents a critical deadlock condition within the SPI subsystem's runtime power management framework. This issue arises from improper handling of system-wide suspend helper calls within the driver's runtime PM hooks, specifically in the ->runtime_suspend() and ->runtime_resume() callback implementations. The problem manifests when the cadence-qspi driver attempts to invoke spi_controller_suspend() and spi_controller_resume() functions from within its runtime power management callbacks, creating a circular dependency that leads to system lockup.
The technical flaw stems from the driver's violation of expected kernel power management patterns where runtime PM callbacks should not invoke system-wide suspend helpers. The spi_controller_suspend() and spi_controller_resume() functions perform two critical operations: they manage the SPI controller's queue operations including kworker handling, and they toggle the SPI_CONTROLLER_SUSPENDED flag by acquiring the ctlr->bus_lock_mutex. The cadence-qspi driver incorrectly attempts to use these helpers despite not requiring queue management functionality, since the driver operates without queuing mechanisms.
The operational impact of this vulnerability is severe as it creates a mutex deadlock condition that fundamentally breaks the SPI controller's operation. When ->runtime_resume() is called from the ->exec_op() callback context, it attempts to acquire the same mutex that is already held by the calling thread, resulting in an irrecoverable deadlock state. This condition prevents any further SPI operations from proceeding once the device enters auto-suspension, effectively disabling the SPI controller's functionality. The call tree demonstrates how spi_mem_exec_op() acquires the bus_lock_mutex, then calls cqspi_exec_mem_op(), which triggers pm_runtime_resume_and_get(), leading to cqspi_resume(), which attempts to acquire the same mutex again, creating the deadlock scenario.
This vulnerability aligns with CWE-121 and CWE-122 categories related to memory safety and improper locking mechanisms, and maps to ATT&CK technique T1059.003 for system command execution through kernel-level operations. The issue directly violates the Linux kernel's power management API contract where runtime PM callbacks should be lightweight and not invoke system-wide suspend operations that could cause resource contention. The fix implemented removes these inappropriate helper calls, allowing the driver to maintain proper runtime power management without interfering with the SPI controller's internal locking mechanisms. Organizations should prioritize applying the kernel patch that resolves this issue, particularly in embedded systems and devices that rely heavily on SPI communication protocols where system stability is critical. The vulnerability affects systems using the cadence-qspi driver and could lead to complete system hangs or unresponsive SPI controllers, making it a high-priority security concern for kernel maintainers and system integrators.