{"api_version":"1","generated_at":"2026-07-18T22:39:25+00:00","cve":"CVE-2025-21807","urls":{"html":"https://cve.report/CVE-2025-21807","api":"https://cve.report/api/cve/CVE-2025-21807.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2025-21807","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2025-21807"},"summary":{"title":"block: fix queue freeze vs limits lock order in sysfs store methods","description":"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->store_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't 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)","state":"PUBLISHED","assigner":"Linux","published_at":"2025-02-27 20:16:03","updated_at":"2026-07-18 16:17:11"},"problem_types":["CWE-667"],"metrics":[{"version":"3.1","source":"nvd@nist.gov","type":"Primary","score":"5.5","severity":"MEDIUM","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","baseScore":5.5,"baseSeverity":"MEDIUM","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"NONE","integrityImpact":"NONE","availabilityImpact":"HIGH"}}],"references":[{"url":"https://git.kernel.org/stable/c/8985da5481562e96b95e94ed8e5cc9b6565eb82b","name":"https://git.kernel.org/stable/c/8985da5481562e96b95e94ed8e5cc9b6565eb82b","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/1645cd7fd42c236c952e9228badcac4fea1829ea","name":"https://git.kernel.org/stable/c/1645cd7fd42c236c952e9228badcac4fea1829ea","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/c99f66e4084a62a2cc401c4704a84328aeddc9ec","name":"https://git.kernel.org/stable/c/c99f66e4084a62a2cc401c4704a84328aeddc9ec","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2025-21807","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21807","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 0327ca9d53bfbb0918867313049bba7046900f73 1645cd7fd42c236c952e9228badcac4fea1829ea git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 0327ca9d53bfbb0918867313049bba7046900f73 8985da5481562e96b95e94ed8e5cc9b6565eb82b git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 0327ca9d53bfbb0918867313049bba7046900f73 c99f66e4084a62a2cc401c4704a84328aeddc9ec git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 6.9","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.9 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.12.96 6.12.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.13.2 6.13.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.14 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[{"cve_year":"2025","cve_id":"21807","vulnerable":"1","versionEndIncluding":"","cpe1":"cpe","cpe2":"2.3","cpe3":"o","cpe4":"linux","cpe5":"linux_kernel","cpe6":"*","cpe7":"*","cpe8":"*","cpe9":"*","cpe10":"*","cpe11":"*","cpe12":"*","cpe13":"*"}],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["block/blk-sysfs.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"1645cd7fd42c236c952e9228badcac4fea1829ea","status":"affected","version":"0327ca9d53bfbb0918867313049bba7046900f73","versionType":"git"},{"lessThan":"8985da5481562e96b95e94ed8e5cc9b6565eb82b","status":"affected","version":"0327ca9d53bfbb0918867313049bba7046900f73","versionType":"git"},{"lessThan":"c99f66e4084a62a2cc401c4704a84328aeddc9ec","status":"affected","version":"0327ca9d53bfbb0918867313049bba7046900f73","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["block/blk-sysfs.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"6.9"},{"lessThan":"6.9","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"6.12.*","status":"unaffected","version":"6.12.96","versionType":"semver"},{"lessThanOrEqual":"6.13.*","status":"unaffected","version":"6.13.2","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"6.14","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.12.96","versionStartIncluding":"6.9","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.13.2","versionStartIncluding":"6.9","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.14","versionStartIncluding":"6.9","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"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->store_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't 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)"}],"providerMetadata":{"dateUpdated":"2026-07-18T15:00:42.201Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/1645cd7fd42c236c952e9228badcac4fea1829ea"},{"url":"https://git.kernel.org/stable/c/8985da5481562e96b95e94ed8e5cc9b6565eb82b"},{"url":"https://git.kernel.org/stable/c/c99f66e4084a62a2cc401c4704a84328aeddc9ec"}],"title":"block: fix queue freeze vs limits lock order in sysfs store methods","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2025-21807","datePublished":"2025-02-27T20:00:59.560Z","dateReserved":"2024-12-29T08:45:45.772Z","dateUpdated":"2026-07-18T15:00:42.201Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2025-02-27 20:16:03","lastModifiedDate":"2026-07-18 16:17:11","problem_types":["CWE-667"],"metrics":{"cvssMetricV31":[{"source":"nvd@nist.gov","type":"Primary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","baseScore":5.5,"baseSeverity":"MEDIUM","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"NONE","integrityImpact":"NONE","availabilityImpact":"HIGH"},"exploitabilityScore":1.8,"impactScore":3.6}]},"configurations":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.9","versionEndExcluding":"6.13.2","matchCriteriaId":"CBC7EFD0-692D-4181-B3E2-3E1C3ABE79D6"}]}]}]},"legacy_mitre":{"record":{"CveYear":"2025","CveId":"21807","Ordinal":"1","Title":"block: fix queue freeze vs limits lock order in sysfs store meth","CVE":"CVE-2025-21807","Year":"2025"},"notes":[{"CveYear":"2025","CveId":"21807","Ordinal":"1","NoteData":"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->store_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't 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)","Type":"Description","Title":"block: fix queue freeze vs limits lock order in sysfs store meth"}]}}}