CVE-2026-74331

firmware_loader: Fix recursive lock in device_cache_fw_images()

N/A
Published: August 15, 2026 at 05:58 AM UTC
Updated: August 17, 2026 at 06:19 AM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
N/A
Exploit prediction
EPSS 0.2%

Description

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.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

3.7 ≤ v < 5.10.2613.7 ≤ v < 5.15.2123.7 ≤ v < 6.1.1783.7 ≤ v < 6.12.973.7 ≤ v < 6.18.403.7 ≤ v < 6.6.1453.7 ≤ v < 7.1.53.7 ≤ v < 7.23.7ac39b3ea73aacde876d1d5ee1ca3e2719f771482
Vendor states this is fixed in 38149b57427c736c08d9aa4c7b87deacd53e9e63 (fixed)
Vendor states this is fixed in 490b0385e4cfac691f7b18dde821c13e77b4770b (fixed)
Vendor states this is fixed in 7865a1bfd20d10c03b083a5fc392d907ca5099b3 (fixed)
Vendor states this is fixed in 806cb8fabfde7f830da5ae87777d52fdf50c4774 (fixed)
Vendor states this is fixed in a5b2a68a391b05d54552f13548a72a46c65006f7 (fixed)
Vendor states this is fixed in c0f2dedd41fe14dbe076c1672214802fb42cd8c8 (fixed)
Vendor states this is fixed in d3ec78f8f8d48a04a9fac38d47275c34645e5103 (fixed)
Vendor states this is fixed in f25d6e4ec4c257030592bd671f113cf9584c52f0 (fixed)
Vendor states this is fixed in 3.7 (unaffected)
Vendor states this is fixed in 5.10.261 (unaffected)
Vendor states this is fixed in 5.15.212 (unaffected)
Vendor states this is fixed in 6.1.178 (unaffected)
Vendor states this is fixed in 6.12.97 (unaffected)
Vendor states this is fixed in 6.18.40 (unaffected)
Vendor states this is fixed in 6.6.145 (unaffected)
Vendor states this is fixed in 7.1.5 (unaffected)
Vendor states this is fixed in 7.2 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card