linux-cve-announce - CVE-2025-21807: block: fix queue freeze vs limits lock order in sysfs store methods

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <2025022753-CVE-2025-21807-a4bb@gregkh>
Date: Thu, 27 Feb 2025 12:00:01 -0800
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: CVE-2025-21807: block: fix queue freeze vs limits lock order in sysfs store methods

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

block: fix queue freeze vs limits lock order in sysfs store methods

queue_attr_store() always freezes a device queue before calling the
attribute store operation. For attributes that control queue limits, the
store operation will also lock the queue limits with a call to
queue_limits_start_update(). However, some drivers (e.g. SCSI sd) may
need to issue commands to a device to obtain limit values from the
hardware with the queue limits locked. This creates a potential ABBA
deadlock situation if a user attempts to modify a limit (thus freezing
the device queue) while the device driver starts a revalidation of the
device queue limits.

Avoid such deadlock by not freezing the queue before calling the
->store_limit() method in struct queue_sysfs_entry and instead use the
queue_limits_commit_update_frozen helper to freeze the queue after taking
the limits lock.

This also removes taking the sysfs lock for the store_limit method as
it doesn't protect anything here, but creates even more nesting.
Hopefully it will go away from the actual sysfs methods entirely soon.

(commit log adapted from a similar patch from  Damien Le Moal)

The Linux kernel CVE team has assigned CVE-2025-21807 to this issue.

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

	Issue introduced in 6.9 with commit 0327ca9d53bfbb0918867313049bba7046900f73 and fixed in 6.13.2 with commit 8985da5481562e96b95e94ed8e5cc9b6565eb82b
	Issue introduced in 6.9 with commit 0327ca9d53bfbb0918867313049bba7046900f73 and fixed in 6.14-rc1 with commit c99f66e4084a62a2cc401c4704a84328aeddc9ec

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-2025-21807
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:
	block/blk-sysfs.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/8985da5481562e96b95e94ed8e5cc9b6565eb82b
	https://git.kernel.org/stable/c/c99f66e4084a62a2cc401c4704a84328aeddc9ec