CVE-2026-68173

Technical Description

In the Linux kernel, the following vulnerability has been resolved:

ublk: wait on ublk_dev_ready() instead of ub->completion

ub->completion is only re-armed by a successful START_USER_RECOVERY. If

the ublk server sends END_USER_RECOVERY without one - e.g. its START

failed with -EBUSY and the error was ignored - the wait is satisfied by

the stale completion of the previous recovery cycle, and the device is

marked LIVE and the requeue list 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(), and after the last FETCH

clears ->canceling nothing ever kicks the requeue list again: the

request is stranded there while holding its tag. If it is the flush

machinery's flush_rq, every subsequent fsync piles up in uninterruptible

sleep and teardown hangs on tag draining. This matches a report of a

lost PREFLUSH with ext4 on top of ublk

Remediation

Check the references section for vendor advisories, patches, and mitigation guidance. If immediate patching is not possible, review the CVSS vector to understand the attack surface and apply compensating controls such as network segmentation or access restrictions.

References