All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-cve-announce@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@kernel.org>
Subject: CVE-2026-74331: firmware_loader: Fix recursive lock in device_cache_fw_images()
Date: Sat, 15 Aug 2026 15:10:58 +0900	[thread overview]
Message-ID: <2026081555-CVE-2026-74331-5c62@gregkh> (raw)

From: Greg Kroah-Hartman <gregkh@kernel.org>

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.

The Linux kernel CVE team has assigned CVE-2026-74331 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 3.7 with commit ac39b3ea73aacde876d1d5ee1ca3e2719f771482 and fixed in 5.10.261 with commit 806cb8fabfde7f830da5ae87777d52fdf50c4774
	Issue introduced in 3.7 with commit ac39b3ea73aacde876d1d5ee1ca3e2719f771482 and fixed in 5.15.212 with commit 7865a1bfd20d10c03b083a5fc392d907ca5099b3
	Issue introduced in 3.7 with commit ac39b3ea73aacde876d1d5ee1ca3e2719f771482 and fixed in 6.1.178 with commit 490b0385e4cfac691f7b18dde821c13e77b4770b
	Issue introduced in 3.7 with commit ac39b3ea73aacde876d1d5ee1ca3e2719f771482 and fixed in 6.6.145 with commit 38149b57427c736c08d9aa4c7b87deacd53e9e63
	Issue introduced in 3.7 with commit ac39b3ea73aacde876d1d5ee1ca3e2719f771482 and fixed in 6.12.97 with commit a5b2a68a391b05d54552f13548a72a46c65006f7
	Issue introduced in 3.7 with commit ac39b3ea73aacde876d1d5ee1ca3e2719f771482 and fixed in 6.18.40 with commit f25d6e4ec4c257030592bd671f113cf9584c52f0
	Issue introduced in 3.7 with commit ac39b3ea73aacde876d1d5ee1ca3e2719f771482 and fixed in 7.1.5 with commit c0f2dedd41fe14dbe076c1672214802fb42cd8c8
	Issue introduced in 3.7 with commit ac39b3ea73aacde876d1d5ee1ca3e2719f771482 and fixed in 7.2-rc1 with commit d3ec78f8f8d48a04a9fac38d47275c34645e5103

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-74331
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	drivers/base/firmware_loader/main.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	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

                 reply	other threads:[~2026-08-15  6:35 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2026081555-CVE-2026-74331-5c62@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=cve@kernel.org \
    --cc=gregkh@kernel.org \
    --cc=linux-cve-announce@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.