CVE-2024-26899: 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'.
Security readout for executives and security teams
Plain-English summary
This Linux kernel issue can cause a storage-related deadlock, meaning affected systems may hang or stall during certain block device and RAID operations. The source bundle does not show data theft, privilege escalation, or active exploitation. The business concern is availability, especially for systems where storage changes or partition scans occur on production hosts.
Executive priority
Handle through the next kernel patch cycle, with expedited scheduling for production storage, virtualization, backup, or RAID-heavy systems. The available evidence supports availability risk, not confirmed compromise or active exploitation.
Technical view
CVE-2024-26899 fixes a deadlock between gendisk open_mutex use during partition scanning and bd_link_disk_holder during holder/slave symlink creation. The described RAID example shows one thread waiting for I/O resume while another waits on open_mutex. The kernel fix introduces blk_holder_mutex instead of reusing open_mutex for that path.
Likely exposure
Exposure is most likely on Linux systems running affected kernel versions around 6.7, 6.7.11, 6.8.2, or related downstream builds that include the faulty block-layer behavior. Risk is higher on hosts with RAID, dynamic block-device changes, or automated partition scanning.
Exploitation context
The provided sources do not report active exploitation, and the CVE is not marked KEV. The evidence describes a reliability flaw triggered by concurrent storage operations, not a public exploit chain. Treat exploitation status as unproven unless vendor or threat-intelligence sources say otherwise.
Researcher notes
The key mechanism is lock misuse: open_mutex protected block-device open and close but was also used for holder-link creation. The fix separates that responsibility with blk_holder_mutex. Source evidence is limited to the CVE description and kernel stable commits; no CVSS, CWE, or exploit details are provided.
Mitigation direction
Check Linux vendor advisories for your distribution kernel package.
Update to a vendor-supported kernel containing the referenced block-layer fix.
Prioritize storage-heavy and RAID hosts for earlier maintenance windows.
Avoid unnecessary live storage reconfiguration on affected production kernels.
Monitor vendor guidance for backported fixed package versions.
Validation and detection
Inventory running kernel versions across Linux servers and appliances.
Confirm whether vendor changelogs include the referenced stable commits.
Review storage hosts for RAID, block-device automation, or partition scanning workflows.
Check system logs for hung tasks or storage-related deadlock symptoms.
Run normal storage regression tests after kernel updates.
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-2024-26899 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.