block: fix deadlock between bd_link_disk_holder and partition scan
In the Linux kernel, the following vulnerability has been resolved: block: fix deadlock between bd_link_disk_holder and partition scan 'open_mutex' of gendisk is used to protect open/close block devices. But in bd_link_disk_holder(), it is used to protect the creation of symlink between holding disk and slave bdev, which introduces some issues. When bd_link_disk_holder() is called, the driver is usually in the process of initialization/modification and may suspend submitting io. At this time, any io hold 'open_mutex', such as scanning partitions, can cause deadlocks. For example, in raid: T1 T2 bdev_open_by_dev lock open_mutex [1] ... efi_partition ... md_submit_bio md_ioctl mddev_syspend -> suspend all io md_add_new_disk bind_rdev_to_array bd_link_disk_holder try lock open_mutex [2] md_handle_request -> wait mddev_resume T1 scan partition, T2 add a new device to raid. T1 waits for T2 to resume mddev, but T2 waits for open_mutex held by T1. Deadlock occurs. Fix it by introducing a local mutex 'blk_holder_mutex' to replace 'open_mutex'.
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 6.7.11, 6.8.2
- CVEs
- CVE-2024-26899
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 4 Nov 2026, 15:10 UTC · Revision 1
Source evidence
block: fix deadlock between bd_link_disk_holder and partition scan
core-osv · Original sourcePublished 17 Apr 2024, 10:27 UTC
In the Linux kernel, the following vulnerability has been resolved: block: fix deadlock between bd_link_disk_holder and partition scan 'open_mutex' of gendisk is used to protect open/close block devices. But in bd_link_disk_holder(), it is used to protect the creation of symlink between holding disk and slave bdev, which introduces some issues. When bd_link_disk_holder() is called, the driver is usually in the process of initialization/modification and may suspend submitting io. At this time, any io hold 'open_mutex', such as scanning partitions, can cause deadlocks. For example, in raid: T1 T2 bdev_open_by_dev lock open_mutex [1] ... efi_partition ... md_submit_bio md_ioctl mddev_syspend -> suspend all io md_add_new_disk bind_rdev_to_array bd_link_disk_holder try lock open_mutex [2] md_handle_request -> wait mddev_resume T1 scan partition, T2 add a new device to raid. T1 waits for T2 to resume mddev, but T2 waits for open_mutex held by T1. Deadlock occurs. Fix it by introducing a local mutex 'blk_holder_mutex' to replace 'open_mutex'.
osv:CVE-2024-26899
Kernel
Fixed versions: 6.7.11, 6.8.2
Complete source record
{
"id": "afee9d99715f094f8f67b8dee8e97c26149ad0fc1e3c5990fd04a7cb5300cf42",
"url": "https://osv.dev/vulnerability/CVE-2024-26899",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "block: fix deadlock between bd_link_disk_holder and partition scan",
"summary": "In the Linux kernel, the following vulnerability has been resolved: block: fix deadlock between bd_link_disk_holder and partition scan 'open_mutex' of gendisk is used to protect open/close block devices. But in bd_link_disk_holder(), it is used to protect the creation of symlink between holding disk and slave bdev, which introduces some issues. When bd_link_disk_holder() is called, the driver is usually in the process of initialization/modification and may suspend submitting io. At this time, any io hold 'open_mutex', such as scanning partitions, can cause deadlocks. For example, in raid: T1 T2 bdev_open_by_dev lock open_mutex [1] ... efi_partition ... md_submit_bio md_ioctl mddev_syspend -> suspend all io md_add_new_disk bind_rdev_to_array bd_link_disk_holder try lock open_mutex [2] md_handle_request -> wait mddev_resume T1 scan partition, T2 add a new device to raid. T1 waits for T2 to resume mddev, but T2 waits for open_mutex held by T1. Deadlock occurs. Fix it by introducing a local mutex 'blk_holder_mutex' to replace 'open_mutex'.",
"evidence": "osv:CVE-2024-26899",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "6.7.11",
"evidence": "/affected/1/ranges"
},
{
"value": "6.8.2",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2024-26899",
"aliases": [
"CVE-2024-26899"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "1b0a2d950ee2a54aa04fb31ead32144be0bbf690"
},
{
"fixed": "1e5c5b0abaee7b62a10b9707a62083b71ad21f62"
},
{
"fixed": "5a87c1f7993bc8ac358a3766bac5dc7126e01e98"
},
{
"fixed": "03f12122b20b6e6028e9ed69030a49f9cffcbb75"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2024-26899.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.7.11"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.8.0"
},
{
"fixed": "6.8.2"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2024-26899.json"
}
}
],
"modified": "2026-10-28T02:30:36.894766449Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/03f12122b20b6e6028e9ed69030a49f9cffcbb75",
"https://git.kernel.org/stable/c/1e5c5b0abaee7b62a10b9707a62083b71ad21f62",
"https://git.kernel.org/stable/c/5a87c1f7993bc8ac358a3766bac5dc7126e01e98",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/26xxx/CVE-2024-26899.json",
"https://nvd.nist.gov/vuln/detail/CVE-2024-26899",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/26xxx/CVE-2024-26899.json"
}
},
"related_cves": [
{
"value": "CVE-2024-26899",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 504041,
"published_at": "2024-04-17T10:27:49.089+00:00"
}