CVE Catalog

CVE-2026-74331

Low risk· EPSS 9%
Published: Updated: Translated: NVD NIST

Exploitation Probability (EPSS)

Low risk
0.19%

9th percentile - higher than 9% of all known CVEs

Summary

In the Linux kernel, the firmware_loader module has a deadlock caused by recursive locking in device_cache_fw_images(). During suspend or hibernation preparation, fw_pm_notify() calls this function, which holds fw_lock while iterating over devices. If memory allocation for the async work fails, the work is executed synchronously, leading to a recursive acquisition of fw_lock and a deadlock.

Risk Assessment

A deadlock can occur during system suspend or hibernation, potentially preventing proper sleep state transition or causing system hang.

Recommendation

Apply the kernel patch that releases fw_lock before iterating over devices to avoid recursive locking.

Other vulnerabilities in Linux kernel

See all
Original NVD description (English source)

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.

Vulnerability data from NVD (NIST) · CISA KEV · EPSS