CVE-2026-74331: Linux Vulnerability

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.

Metrics

EPSS Probability

0.19%

9.0th percentile

Probability of exploitation in the next 30 days. Learn more

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

Vendor	Product	Versions
Linux	Linux	>= ac39b3ea73aacde876d1d5ee1ca3e2719f771482, < 806cb8fabfde7f830da5ae87777d52fdf50c4774; >= ac39b3ea73aacde876d1d5ee1ca3e2719f771482, < 7865a1bfd20d10c03b083a5fc392d907ca5099b3; >= ac39b3ea73aacde876d1d5ee1ca3e2719f771482, < 490b0385e4cfac691f7b18dde821c13e77b4770b; >= ac39b3ea73aacde876d1d5ee1ca3e2719f771482, < 38149b57427c736c08d9aa4c7b87deacd53e9e63; >= ac39b3ea73aacde876d1d5ee1ca3e2719f771482, < a5b2a68a391b05d54552f13548a72a46c65006f7; >= ac39b3ea73aacde876d1d5ee1ca3e2719f771482, < f25d6e4ec4c257030592bd671f113cf9584c52f0; >= ac39b3ea73aacde876d1d5ee1ca3e2719f771482, < c0f2dedd41fe14dbe076c1672214802fb42cd8c8; >= ac39b3ea73aacde876d1d5ee1ca3e2719f771482, < d3ec78f8f8d48a04a9fac38d47275c34645e5103
Linux	Linux	3.7

References

Timeline

Published: Aug 15, 2026
Last Modified: Aug 17, 2026
Status: Received

Frequently Asked Questions

What is CVE-2026-74331?

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.

How severe is CVE-2026-74331?

Severity scoring for CVE-2026-74331 is pending analysis. The EPSS model estimates a 0.19% probability of exploitation in the next 30 days.

How do I fix CVE-2026-74331?

Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

View all 2026CVEs →