CVE-2024-26899

What it actually does

The vulnerability is a deadlock caused by misuse of the gendisk open_mutex to protect both device open/close operations and creation of holder symlinks in bd_link_disk_holder; when a thread holds the mutex during partition scanning while another thread suspends I/O and attempts to acquire the same mutex during device addition (e.g., RAID), the threads wait on each other indefinitely.

Why it matters to the business

Linux systems, especially those using RAID arrays or dynamic block device reconfiguration, can experience kernel-level hangs that require reboot, disrupting storage services and potentially causing data unavailability or loss of ongoing operations.

How an attack unfolds

A local attacker with privileges to trigger block device operations concurrently initiates partition scanning (holding open_mutex) while a device driver initialization or modification path suspends I/O and calls bd_link_disk_holder, resulting in mutual waiting and deadlock; no remote or unauthenticated exploitation is indicated.

How to fix it

Upgrade the Linux kernel to a version containing commit 1e5c5b0abaee7b62a10b9707a62083b71ad21f62 which introduces blk_holder_mutex to protect holder symlink creation separately from open_mutex.

How to confirm the fix worked

Confirm the running kernel contains commit 1e5c5b0abaee7b62a10b9707a62083b71ad21f62 or a later equivalent; attempt to reproduce the deadlock scenario under load with concurrent partition scans and device additions to verify absence of hang.

Typical attack path

1. Obtain local access and privileges sufficient to open block devices and issue partition scans.
2. Trigger concurrent device addition or modification that suspends I/O and invokes bd_link_disk_holder.
3. Cause the two code paths to contend on open_mutex, inducing deadlock.
4. Observe system hang affecting storage I/O and requiring manual intervention.

How to detect it

Review kernel logs for hung task or deadlock warnings involving md_ioctl, bd_link_disk_holder, or open_mutex; inspect dmesg and syslog for blocked processes during device initialization or partition scans.

What your security team should do

• Prioritize kernel updates on systems using RAID, md, or dynamic block device management.
• Apply the fix across all affected stable branches as soon as packages are available.
• Monitor for kernel oops or hung task reports related to block layer mutexes.
• Restrict untrusted local access on multi-user systems until patched.