CVE-2026-68173: Linux Kernel ublk DOS Vulnerability

CVE-2026-68173 Overview

CVE-2026-68173 is a race condition in the Linux kernel's ublk (userspace block device) subsystem. The flaw affects recovery handling when a ublk server issues END_USER_RECOVERY without a preceding successful START_USER_RECOVERY. The kernel waits on a stale completion latch (ub->completion) instead of the actual readiness condition, causing the device to be marked LIVE while queues are still in a canceling state. Requests can become stranded while holding their tags, and downstream flush operations pile up in uninterruptible sleep. A reported failure case involves a lost PREFLUSH with ext4 on top of ublk following daemon crash recovery.

Critical Impact
Local attackers or faulty userspace daemons can trigger permanent I/O hangs, stranded requests, and denial of service on systems using ublk-backed block devices.

Affected Products

Linux kernel builds containing the ublk driver prior to the fix commits
Distributions shipping affected stable kernels referencing commits 432a9b2, 7dd26ad, and 8f188dd
Systems using userspace block device servers on top of ublk (for example ext4 on ublk)

Discovery Timeline

2026-08-10 - CVE-2026-68173 published to NVD
2026-08-13 - Last updated in NVD database

Technical Details for CVE-2026-68173

Vulnerability Analysis

The root of the flaw is that ub->completion is an edge-triggered latch used as a proxy for the level condition "every queue has fetched all I/O commands." The latch is only re-armed by a successful START_USER_RECOVERY. When a ublk server sends END_USER_RECOVERY without one, for example when START failed with -EBUSY and the error was ignored, the wait is satisfied by the stale completion from the previous recovery cycle.

The device is then marked LIVE and the requeue list is kicked while the FETCH stream is still running and ubq->canceling is still set. The kick redispatches a previously requeued request, __ublk_queue_rq_common() sees ->canceling and parks it again via __ublk_abort_rq(). After the last FETCH clears ->canceling, nothing kicks the requeue list again, so the request stays stranded while holding its tag.

Root Cause

The design flaw is using an edge-triggered completion as a proxy for a level condition that can regress. The F_BATCHUNPREP path and daemon death can both regress readiness, and the re-arm of the latch can be skipped entirely. The fix replaces the latch with ublk_wait_dev_ready_and_lock(), which waits on ublk_dev_ready() via wait_var_event_interruptible() and re-checks readiness under ub->mutex.

Attack Vector

Exploitation requires local access with the ability to drive a ublk control device or to run a ublk server daemon that crashes and recovers incorrectly. A malicious or faulty daemon that issues END_USER_RECOVERY after a failed START_USER_RECOVERY triggers the stranded-tag condition. Once a flush request (flush_rq) is stranded, every subsequent fsync piles up in uninterruptible sleep, and teardown hangs on tag draining.

Detection Methods for CVE-2026-68173

Indicators of Compromise

Processes stuck in uninterruptible sleep (D state) with stack traces referencing blk_flush_complete_seq or wait_for_completion under ublk
ublk block devices reporting LIVE state while active tags remain outstanding indefinitely
Kernel logs showing repeated __ublk_abort_rq activity around daemon restarts

Detection Strategies

Monitor ublk server daemons for exit or restart events immediately followed by ext4 or other filesystem fsync stalls
Inspect /sys/kernel/debug/block/<dev>/hctx*/tags to identify tags held by requests that never complete after a ublk recovery cycle
Correlate START_USER_RECOVERY failures returning -EBUSY with subsequent END_USER_RECOVERY control commands

Monitoring Recommendations

Alert on kernel hung_task warnings involving ublk or filesystems layered on top of ublk devices
Track the running kernel version against the fix commits 432a9b2, 7dd26ad, and 8f188dd
Baseline ublk daemon restart frequency and investigate any spike that coincides with I/O latency alerts

How to Mitigate CVE-2026-68173

Immediate Actions Required

Apply the upstream stable kernel updates that include the three referenced fix commits
Restart hosts after patching to ensure the corrected ublk_wait_dev_ready_and_lock() code path is in effect
Audit userspace ublk server daemons to ensure they do not send END_USER_RECOVERY without a successful START_USER_RECOVERY

Patch Information

The fix is delivered by three upstream commits: Kernel Git Commit 432a9b2, Kernel Git Commit 7dd26ad, and Kernel Git Commit 8f188dd. The change drops the edge-triggered ub->completion latch and waits on the real ublk_dev_ready() condition under ub->mutex, ensuring END_USER_RECOVERY marks the device LIVE strictly after ->canceling clears.

Workarounds

Restrict access to /dev/ublk-control so only trusted service accounts can issue recovery control commands
Avoid deploying ublk-backed storage in production workloads until the patched kernel is rolled out
Ensure ublk server daemons treat START_USER_RECOVERY errors as fatal and do not proceed to END_USER_RECOVERY

bash

# Verify running kernel and check for the fix commits
uname -r
# On distributions that ship changelogs, confirm inclusion:
rpm -q --changelog kernel | grep -E '432a9b2|7dd26ad|8f188dd'
# Restrict access to the ublk control device
chmod 0600 /dev/ublk-control
chown root:root /dev/ublk-control