CVE-2024-26899 in Linux
Summary
by MITRE • 04/17/2024
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'.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 12/04/2025
The vulnerability described in CVE-2024-26899 represents a critical deadlock condition within the Linux kernel's block layer subsystem that arises from improper mutex usage during disk holder management operations. This issue specifically affects the interaction between the bd_link_disk_holder function and partition scanning processes, creating a circular dependency that can bring system operations to a complete halt. The problem manifests when the open_mutex associated with gendisk structures is used not only for protecting open/close block device operations but also for safeguarding the creation of symbolic links between holding disks and slave block devices, fundamentally altering the mutex's intended scope and purpose.
The technical flaw stems from the improper reuse of the existing open_mutex for protecting symlink creation operations during disk holder linking, which introduces a timing dependency that can lead to deadlock conditions. When a driver initializes or modifies a disk device, it may suspend I/O operations, but concurrent partition scanning activities that require holding the same open_mutex can create a deadlock scenario. The specific deadlock occurs when one thread attempts to scan partitions while holding the open_mutex, and another thread tries to add a new device to a RAID array, requiring the same mutex for bd_link_disk_holder operations. This creates a circular wait condition where each thread waits for the other to release the mutex it holds, effectively freezing the system's block I/O operations.
The operational impact of this vulnerability is severe as it can cause complete system freezes during critical operations such as RAID array modifications or partition scanning activities. The deadlock specifically affects storage subsystems that rely heavily on dynamic disk management and RAID configurations, where adding new devices or performing partition operations can trigger the problematic code path. Systems running with complex storage configurations, particularly those using software RAID implementations, are most susceptible to this vulnerability, as they frequently invoke the bd_link_disk_holder function during device management operations. The potential for system instability extends beyond simple hangs to complete service disruption in production environments where storage operations are frequent and critical.
The fix implemented addresses this vulnerability by introducing a dedicated local mutex named blk_holder_mutex specifically for protecting disk holder linking operations, thereby separating the concerns of device open/close operations from symlink creation activities. This approach aligns with the principle of least privilege and proper resource management as recommended by security best practices and follows the CWE-362 principle of avoiding improper locking mechanisms. The solution eliminates the circular dependency by ensuring that partition scanning operations and disk holder linking operations can proceed independently without competing for the same mutex. This mitigation strategy reduces the attack surface and prevents the deadlock scenario while maintaining the necessary synchronization for proper device management operations, as outlined in the ATT&CK framework's approach to system integrity protection through proper resource management and mutex handling.