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

"Danilo Krummrich" <[email protected]>
Newsgroups dev.linux.lists.syzbot,dev.linux.lists.driver-core,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
On Fri May 29, 2026 at 5:09 PM CEST, syzbot wrote:
> From: Dmitry Vyukov <[email protected]>
>
> 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: [email protected]
> 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 <[email protected]>

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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.