CVE-2026-74331 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
firmware_loader: Fix recursive lock in device_cache_fw_images()
A recursive locking deadlock can occur in the firmware loader's power management notification handler.
During system suspend or hibernation preparation, fw_pm_notify() calls device_cache_fw_images(). This function acquires fw_lock to set the firmware cache state to FW_LOADER_START_CACHE and then iterates over all devices using dpm_for_each_dev() while still holding the lock.
For each device, dev_cache_fw_image() schedules asynchronous work to cache the firmware. If memory allocation for the async work entry fails (e.g., in out-of-memory conditions), async_schedule_node_domain() falls back to executing the work function synchronously in the current thread.
The synchronous execution path (__async_dev_cache_fw_image() -> cache_firmware() -> request_firmware() -> assign_fw()) attempts to acquire fw_lock again. Since the current thread already holds fw_lock, this results in a recursive locking deadlock.
Fix this by releasing fw_lock immediately after updating the cache state and before calling dpm_for_each_dev(). The lock is only needed to protect the state update. Concurrent firmware requests will correctly see the FW_LOADER_START_CACHE state and use the piggyback mechanism, which is independently protected by its own fwc->name_lock.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability described represents a critical recursive locking issue within the linux kernel's firmware loading subsystem that can lead to system deadlock during power management operations. This flaw specifically affects the firmware loader's handling of device cache operations during system suspend or hibernation sequences, creating a scenario where the same lock is acquired multiple times in a recursive manner.
The technical root cause stems from improper lock management within the fw_pm_notify() function which orchestrates the firmware caching process during power state transitions. When system suspend or hibernation preparation begins, the function calls device_cache_fw_images() to prepare firmware cache states for all devices. The implementation initially acquires the fw_lock mutex to set the firmware cache state to FW_LOADER_START_CACHE and then proceeds to iterate through all devices using dpm_for_each_dev() while maintaining the lock acquisition throughout this process.
The operational impact becomes apparent when asynchronous work scheduling fails due to memory allocation constraints during firmware caching operations. When async_schedule_node_domain() cannot allocate memory for the async work entry, it falls back to synchronous execution of the work function within the current thread context. This synchronous execution path leads to a recursive lock acquisition scenario where __async_dev_cache_fw_image() -> cache_firmware() -> request_firmware() -> assign_fw() attempts to acquire fw_lock again while the calling thread already holds this same lock, resulting in an immediate deadlock condition.
This vulnerability aligns with CWE-367 weakness classification related to time-of-check to time-of-use race conditions and represents a classic example of improper locking protocol that violates fundamental concurrency control principles. The flaw demonstrates poor understanding of lock scope management where locks are held longer than necessary for their intended protection purposes, creating potential deadlocks in concurrent systems.
The fix implements proper lock discipline by releasing fw_lock immediately after updating the cache state and before initiating the device iteration process through dpm_for_each_dev(). This approach ensures that the lock is only held for the minimal required duration to protect the state update operation. The solution correctly recognizes that the primary purpose of fw_lock in this context is to protect the cache state transition rather than to serialize all subsequent operations on the device list.
The resolution maintains proper concurrent firmware request handling through the piggyback mechanism which operates independently with its own fwc->name_lock protection, ensuring that legitimate firmware requests can proceed correctly while preventing the recursive deadlock scenario. This fix addresses the ATT&CK technique T1486 related to system shutdown/reboot and aligns with security best practices for lock management in kernel space operations.
The vulnerability demonstrates how seemingly minor concurrency control issues can escalate into critical system stability problems, particularly during power management transitions where system responsiveness and reliability are paramount. The solution emphasizes that locks should be held for the shortest possible duration to minimize contention and deadlock risks while ensuring proper state protection mechanisms remain intact throughout the concurrent execution environment.