Back

MEDIUM

firmware_loader: Fix recursive lock in device_cache_fw_images()

Published Aug 15, 2026

Description

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.

Affected products

Remediation

No remediation recorded yet.

Metrics

Weaknesses (1)

References (13)

Change history (0)

No recorded changes yet.

Sources
CVE.org / MITRE
Status PUBLISHED
Assigner Linux
Published Aug 15, 2026
Updated Aug 17, 2026
Reserved Aug 15, 2026
NVD
Status Received
Modified Aug 17, 2026
Red Hat
Severity Low
Public date Aug 15, 2026