CVE-2026-68173

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ublk: wait on ublk_dev_ready() instead of ub-&gt;completion<br /> <br /> ub-&gt;completion is only re-armed by a successful START_USER_RECOVERY. If<br /> the ublk server sends END_USER_RECOVERY without one - e.g. its START<br /> failed with -EBUSY and the error was ignored - the wait is satisfied by<br /> the stale completion of the previous recovery cycle, and the device is<br /> marked LIVE and the requeue list kicked while the FETCH stream is still<br /> running and ubq-&gt;canceling is still set. The kick redispatches a<br /> previously requeued request, __ublk_queue_rq_common() sees -&gt;canceling<br /> and parks it again via __ublk_abort_rq(), and after the last FETCH<br /> clears -&gt;canceling nothing ever kicks the requeue list again: the<br /> request is stranded there while holding its tag. If it is the flush<br /> machinery&amp;#39;s flush_rq, every subsequent fsync piles up in uninterruptible<br /> sleep and teardown hangs on tag draining. This matches a report of a<br /> lost PREFLUSH with ext4 on top of ublk after daemon crash recovery.<br /> <br /> ub-&gt;completion is an edge-triggered latch used as a proxy for the level<br /> condition "every queue has fetched all I/O commands", which can regress<br /> (F_BATCH&amp;#39;s UNPREP, daemon death) and whose re-arm can be skipped. Drop<br /> it and wait on the real condition instead: the new helper<br /> ublk_wait_dev_ready_and_lock() waits on ublk_dev_ready() via<br /> wait_var_event_interruptible(), woken from ublk_mark_io_ready(), then<br /> re-checks it under ub-&gt;mutex, waiting again on regression, and returns<br /> with the mutex held and readiness guaranteed.<br /> <br /> Readiness becomes true in the same ub-&gt;mutex critical section that<br /> clears the last queue&amp;#39;s -&gt;canceling, so END_USER_RECOVERY marks the<br /> device LIVE and kicks the requeue list strictly after -&gt;canceling<br /> clears. The wait stays interruptible, so a server whose daemon died can<br /> still be signalled out. For ublk_ctrl_start_dev() this replaces the<br /> fail-fast -EINVAL on an F_BATCH ready-&gt;UNPREP regression with waiting<br /> until the device is ready again.