CVE-2024-47672 in Linux
Summary
by MITRE • 10/09/2024
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: don't wait for tx queues if firmware is dead
There is a WARNING in iwl_trans_wait_tx_queues_empty() (that was recently converted from just a message), that can be hit if we wait for TX queues to become empty after firmware died. Clearly, we can't expect anything from the firmware after it's declared dead.
Don't call iwl_trans_wait_tx_queues_empty() in this case. While it could be a good idea to stop the flow earlier, the flush functions do some maintenance work that is not related to the firmware, so keep that part of the code running even when the firmware is not running.
[edit commit message]
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 03/21/2026
The vulnerability in question affects the iwlwifi wireless driver within the Linux kernel, specifically within the mvm (multimedia) subsystem responsible for managing Intel wireless network adapters. This issue stems from a problematic handling scenario where the driver attempts to wait for transmission queues to become empty after the firmware has already been declared dead, creating a logical inconsistency in the driver's state management. The technical flaw manifests in the iwl_trans_wait_tx_queues_empty() function which was recently converted from a simple informational message to a warning condition, but this conversion introduces a critical race condition and improper state handling when dealing with firmware failures.
The operational impact of this vulnerability becomes significant during wireless network adapter shutdown or error recovery scenarios where firmware crashes or becomes unresponsive. When the driver detects that firmware is dead, it should not attempt to wait for transmission queues to drain since there is no active firmware component capable of processing these operations. The warning condition in iwl_trans_wait_tx_queues_empty() creates a situation where the system may hang or enter an inconsistent state, as it waits indefinitely for hardware resources that will never become available due to the firmware failure. This behavior violates fundamental principles of error recovery and resource management within kernel drivers.
This vulnerability aligns with CWE-691, which addresses insufficient control flow management in software systems, and demonstrates poor error handling practices that can lead to system instability or denial of service conditions. The fix implemented addresses the specific ATT&CK technique T1489, which involves affecting availability by disrupting system services through improper error handling and resource management. The solution involves modifying the driver's behavior to avoid calling iwl_trans_wait_tx_queues_empty() when firmware is dead while preserving other cleanup operations that are essential for proper resource management.
The mitigation strategy focuses on proper state checking before attempting hardware-dependent operations, ensuring that driver cleanup functions can proceed with maintenance tasks unrelated to firmware operations even when the firmware component is non-functional. This approach maintains system stability during error recovery by allowing critical housekeeping operations to complete while preventing the driver from waiting indefinitely for hardware resources that will never become available. The fix represents a fundamental improvement in the driver's fault tolerance and robustness, aligning with best practices for kernel module error handling and resource management as outlined in the Linux kernel documentation and security guidelines.
The vulnerability demonstrates how seemingly minor code conversions can introduce critical system stability issues, particularly in drivers where timing and state management are crucial. By maintaining separate execution paths for firmware-dependent operations versus independent maintenance functions, the driver achieves better error recovery capabilities and prevents potential system hangs or crashes during wireless adapter failure scenarios. This fix reinforces the principle that kernel drivers must gracefully handle error conditions without compromising overall system stability through improper resource waiting or state management decisions.