CVE-2026-74331None▾ SunlitIn 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. …
▾ Sunlit zone — Low / medium · no exploitation signal
impact 2.8 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Stakeholder-Specific Vulnerability Categorization from CISA's ADP record at CVE.org: whether exploitation is observed, whether an attack can be automated, and how much of the system is at stake.
Exploit-prediction probability, daily snapshots since Nov 6.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via CVEORG
Last analysed / modified upstream
0.2%
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.
Linux >= ac39b3ea73aacde876d1d5ee1ca3e2719f771482 < 806cb8fabfde7f830da5ae87777d52fdf50c4774Linux >= ac39b3ea73aacde876d1d5ee1ca3e2719f771482 < 7865a1bfd20d10c03b083a5fc392d907ca5099b3Linux >= ac39b3ea73aacde876d1d5ee1ca3e2719f771482 < 490b0385e4cfac691f7b18dde821c13e77b4770bLinux >= ac39b3ea73aacde876d1d5ee1ca3e2719f771482 < 38149b57427c736c08d9aa4c7b87deacd53e9e63Linux >= ac39b3ea73aacde876d1d5ee1ca3e2719f771482 < a5b2a68a391b05d54552f13548a72a46c65006f7Linux >= ac39b3ea73aacde876d1d5ee1ca3e2719f771482 < f25d6e4ec4c257030592bd671f113cf9584c52f0Linux >= ac39b3ea73aacde876d1d5ee1ca3e2719f771482 < c0f2dedd41fe14dbe076c1672214802fb42cd8c8Linux >= ac39b3ea73aacde876d1d5ee1ca3e2719f771482 < d3ec78f8f8d48a04a9fac38d47275c34645e5103Linux 3.7Refer to the linked advisories for vendor-supplied fixes and affected version ranges.
Connected by shared product, vendor, weakness, or advisory.
CVE-2026-99284Nonenet: skbuff: propagate shared-frag marker in skb_zerocopy()
CVE-2026-99283Nonenetfilter: conntrack: tcp: use UNACK timeout for non-closing RST packets
CVE-2026-99272Nonesmb: client: validate the data area in SMB2_read()
CVE-2026-99271NoneALSA: line6: Clear prev_fbuf on capture buffer release
CVE-2026-99273Noneksmbd: reserve space for the UTF-16 terminator in stream info
CVE-2026-99275Nonesmb: client: reject short SESSION_SETUP responses