[PATCH v2] firmware_loader: Fix recursive lock in device_cache_fw_images()

[PATCH v2] firmware_loader: Fix recursive lock in device_cache_fw_images()

[syzbot]

From: Dmitry Vyukov <dvyukov@google.com>

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.

Fixes: ac39b3ea73aa ("firmware loader: let caching firmware piggyback on loading firmware")
Assisted-by: Gemini:gemini-3.1-pro-preview Gemini:gemini-3-flash-preview syzbot
Reported-by: syzbot+e70e4c6f6eee43357ba7@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=e70e4c6f6eee43357ba7
Link: https://syzkaller.appspot.com/ai_job?id=8b4af9fd-24af-423f-8acb-1159fd34c1a5
Signed-off-by: Dmitry Vyukov <dvyukov@google.com>

---
v2:
- Resend to fix the From: line as requested by reviewer.

v1:
https://lore.kernel.org/all/dff1dcc7-59bd-40c7-981e-bd805ae6b3c1@mail.kernel.org/T/
---
diff --git a/drivers/base/firmware_loader/main.c b/drivers/base/firmware_loader/main.c
index a11b30dda..c96312ac2 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -1503,9 +1503,10 @@ static void device_cache_fw_images(void)
 
 	mutex_lock(&fw_lock);
 	fwc->state = FW_LOADER_START_CACHE;
-	dpm_for_each_dev(NULL, dev_cache_fw_image);
 	mutex_unlock(&fw_lock);
 
+	dpm_for_each_dev(NULL, dev_cache_fw_image);
+
 	/* wait for completion of caching firmware for all devices */
 	async_synchronize_full_domain(&fw_cache_domain);
 


base-commit: 7fd2df204f342fc17d1a0bfcd474b24232fb0f32
-- 
See https://goo.gle/syzbot-ai-patches for information about AI-generated patches.
You can comment on the patch as usual, syzbot will try to address
the comments and send a new version of the patch if necessary.
syzbot engineers can be reached at syzkaller@googlegroups.com.

Re: [PATCH v2] firmware_loader: Fix recursive lock in device_cache_fw_images()

[Danilo Krummrich]

On Fri May 29, 2026 at 5:09 PM CEST, syzbot wrote:
> From: Dmitry Vyukov <dvyukov@google.com>
>
> 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.
>
> Fixes: ac39b3ea73aa ("firmware loader: let caching firmware piggyback on loading firmware")
> Assisted-by: Gemini:gemini-3.1-pro-preview Gemini:gemini-3-flash-preview syzbot
> Reported-by: syzbot+e70e4c6f6eee43357ba7@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=e70e4c6f6eee43357ba7
> Link: https://syzkaller.appspot.com/ai_job?id=8b4af9fd-24af-423f-8acb-1159fd34c1a5
> Signed-off-by: Dmitry Vyukov <dvyukov@google.com>

I think Sashiko found an orthogonal issue that looks valid at a first glance, in
case you are interested to dig in further.

[1] https://sashiko.dev/#/patchset/48b092a5-f49d-48a4-95f4-f65bebfc6bc3%40mail.kernel.org

Re: [PATCH v2] firmware_loader: Fix recursive lock in device_cache_fw_images()

[Danilo Krummrich]

On Fri, 29 May 2026 15:09:06 +0000 (UTC), syzbot wrote:
> [PATCH v2] firmware_loader: Fix recursive lock in device_cache_fw_images()

Applied, thanks!

  Branch: driver-core-testing
  Tree:   git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core.git

[1/1] firmware_loader: Fix recursive lock in device_cache_fw_images()
      commit: d3ec78f8f8d4

The patch will appear in the next linux-next integration (typically within 24
hours on weekdays).

The patch is in the driver-core-testing branch and will be promoted to
driver-core-next after validation.