ghsa-cp43-x3rr-gwcc
Vulnerability from github
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)
{
"affected": [],
"aliases": [
"CVE-2025-21807"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-27T20:16:03Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock: fix queue freeze vs limits lock order in sysfs store methods\n\nqueue_attr_store() always freezes a device queue before calling the\nattribute store operation. For attributes that control queue limits, the\nstore operation will also lock the queue limits with a call to\nqueue_limits_start_update(). However, some drivers (e.g. SCSI sd) may\nneed to issue commands to a device to obtain limit values from the\nhardware with the queue limits locked. This creates a potential ABBA\ndeadlock situation if a user attempts to modify a limit (thus freezing\nthe device queue) while the device driver starts a revalidation of the\ndevice queue limits.\n\nAvoid such deadlock by not freezing the queue before calling the\n-\u003estore_limit() method in struct queue_sysfs_entry and instead use the\nqueue_limits_commit_update_frozen helper to freeze the queue after taking\nthe limits lock.\n\nThis also removes taking the sysfs lock for the store_limit method as\nit doesn\u0027t protect anything here, but creates even more nesting.\nHopefully it will go away from the actual sysfs methods entirely soon.\n\n(commit log adapted from a similar patch from Damien Le Moal)",
"id": "GHSA-cp43-x3rr-gwcc",
"modified": "2025-02-27T21:32:16Z",
"published": "2025-02-27T21:32:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21807"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8985da5481562e96b95e94ed8e5cc9b6565eb82b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c99f66e4084a62a2cc401c4704a84328aeddc9ec"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.