CVE-2025-21807: block: fix queue freeze vs limits lock order in sysfs store methods
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)
Security readout for executives and security teams
Plain-English summary
CVE-2025-21807 is a Linux kernel block-layer deadlock issue. Certain block device queue limit updates through sysfs can conflict with driver revalidation work, potentially causing affected storage queue operations to hang. Public sources do not provide CVSS, CWE, or evidence of active exploitation.
Executive priority
Treat this as a targeted availability risk for Linux storage systems, not a confirmed widespread attack issue. Prioritize patch validation on critical servers, virtualization hosts, and storage-intensive workloads, especially where kernel updates are already scheduled or storage hangs would be costly.
Technical view
queue_attr_store() froze the device queue before limit-store callbacks. Limit store paths also take the queue limits lock, while drivers such as SCSI sd may revalidate limits and issue device commands while holding that lock. This creates a potential ABBA deadlock. The fix changes limit-store handling to take limits locking first and freeze later via queue_limits_commit_update_frozen.
Likely exposure
Exposure is most relevant on Linux systems running affected kernel versions where users or management tooling can write block queue limit attributes in sysfs. Business impact is likely availability-related for storage operations. Exact exposure depends on kernel version, backports, and distribution packaging.
Exploitation context
The public record describes a deadlock triggered by modifying queue limits while a driver revalidates device limits. CISA KEV status is false in the provided data, and no cited source reports active exploitation. The sources do not describe remote exploitation.
Researcher notes
Evidence is limited to the CVE record and Linux stable commit references. No CVSS, CWE, exploit status, or distribution-specific package data is provided. The core issue is lock-order inversion between queue freezing and queue limits locking in sysfs store paths.
Mitigation direction
Apply a Linux kernel update containing the referenced stable fixes.
Check your Linux distribution advisory for backported fixes and affected package versions.
Restrict write access to block queue sysfs attributes to trusted administrators.
Prioritize storage-heavy hosts and systems using SCSI block devices for review.
Validation and detection
Inventory Linux kernel versions across servers and appliances.
Compare installed kernels against vendor advisories and the referenced stable commits.
Confirm updated kernels include the block queue limit locking fix.
Review change-management tools that write block queue sysfs limit attributes.
Monitor affected systems for unexplained storage hangs until patched.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-21807 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
4Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Feb 27, 2025, 20:00 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.