CVE-2025-68823: Linux Kernel ublk Deadlock Vulnerability

CVE-2025-68823 Overview

A deadlock vulnerability has been identified in the Linux kernel's ublk (userspace block driver) subsystem. The issue occurs when a process, such as udev, opens a ublk block device to read the partition table. This can trigger a deadlock condition where the same task attempts to acquire a mutex it already holds, resulting in system hangs.

Critical Impact

This vulnerability can cause complete system hangs when accessing ublk block devices, affecting system availability and potentially disrupting critical storage operations.

Affected Products

• Linux kernel with ublk subsystem enabled
• Systems using userspace block drivers (ublk)
• Environments where udev or similar processes scan block devices

Discovery Timeline

• January 13, 2026 - CVE-2025-68823 published to NVD
• January 13, 2026 - Last updated in NVD database

Technical Details for CVE-2025-68823

Vulnerability Analysis

This deadlock vulnerability exists in the Linux kernel's ublk block driver subsystem. The vulnerability manifests during the partition table reading process when a user-space process opens a ublk block device.

The deadlock sequence begins when bdev_open() acquires the disk->open_mutex lock. Subsequently, when a read I/O operation is issued to the ublk backend to read the partition table, the __ublk_complete_rq() function executes blk_update_request() or blk_mq_end_request(), which runs bio->bi_end_io() callbacks.

If these callbacks trigger an fput() operation on the ublk block device file descriptor, the work may be deferred to the current task's task work context due to the fput() implementation. This eventually calls blkdev_release() from the same context, which attempts to acquire disk->open_mutex again—the same mutex the task already holds, creating a classic deadlock scenario.

Root Cause

The root cause is improper synchronization in the I/O completion path of the ublk driver. When block I/O completion callbacks trigger file descriptor cleanup operations within the same task context, the cleanup code path attempts to re-acquire the disk->open_mutex that was already held during the initial block device open operation. This violates the mutex locking hierarchy and creates a self-deadlock condition.

Attack Vector

The vulnerability can be triggered during normal system operations when:

1. A user-space process (commonly udev during device discovery) opens a ublk block device
2. The process issues read operations to scan partition tables
3. I/O completion callbacks execute within the same task context
4. File descriptor cleanup operations are deferred to task work
5. The cleanup attempts to acquire an already-held mutex

This is primarily a local availability issue that can be triggered through standard block device access patterns.

Detection Methods for CVE-2025-68823

Indicators of Compromise

• System hangs occurring when accessing ublk block devices
• Kernel soft lockup warnings in system logs mentioning ublk or block device operations
• Tasks stuck in uninterruptible sleep state (D state) related to ublk driver
• Mutex acquisition timeouts in kernel logs referencing disk->open_mutex

Detection Strategies

• Monitor for kernel soft lockup warnings in /var/log/kern.log or dmesg output
• Watch for hung task warnings specifically mentioning ublk-related functions
• Deploy kernel debugging tools to detect mutex contention in block subsystem
• Review ftrace output for suspicious locking patterns in ublk code paths

Monitoring Recommendations

• Enable kernel lockup detection (CONFIG_DETECT_HUNG_TASK=y) to catch deadlock conditions
• Configure watchdog timers to alert on system unresponsiveness
• Monitor process states for tasks stuck in ublk-related kernel code
• Set up alerting for kernel panic or soft lockup events in centralized logging systems

How to Mitigate CVE-2025-68823

Immediate Actions Required

• Update the Linux kernel to a patched version containing the deadlock fix
• Consider temporarily disabling ublk functionality if not critical to operations
• Monitor systems for signs of deadlock conditions during device discovery phases
• Plan maintenance windows for kernel updates on affected systems

Patch Information

The vulnerability has been addressed in the Linux kernel through commits that modify the I/O completion handling in the ublk driver. The fix involves running blk_update_request() and blk_mq_end_request() with bottom halves disabled, which forces blkdev_release() to execute in kernel work-queue context rather than the current task work context. This prevents the deadlock by ensuring mutex acquisition occurs in a different execution context.

Patch commits are available:

• Kernel Git Commit 0460e09a614291f06c008443f47393c37b7358e7
• Kernel Git Commit c258f5c4502c9667bccf5d76fa731ab9c96687c1

Workarounds

• Temporarily disable automatic block device scanning by udev for ublk devices
• Configure udev rules to skip partition probing on ublk block devices until patched
• Reduce concurrent access to ublk devices during system boot and device discovery
• Consider using alternative block driver implementations if available and suitable for your use case

# Configuration example - Disable udev partition scanning for ublk devices
# Add to /etc/udev/rules.d/99-ublk-workaround.rules
KERNEL=="ublk*", OPTIONS+="nowatch", ENV{UDISKS_IGNORE}="1"