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:

A user-space process (commonly udev during device discovery) opens a ublk block device
The process issues read operations to scan partition tables
I/O completion callbacks execute within the same task context
File descriptor cleanup operations are deferred to task work
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:

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

bash

# 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"