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

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

[Greg Kroah-Hartman]

From: Greg Kroah-Hartman <gregkh@kernel.org>

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 after daemon crash recovery.

ub->completion is an edge-triggered latch used as a proxy for the level
condition "every queue has fetched all I/O commands", which can regress
(F_BATCH's UNPREP, daemon death) and whose re-arm can be skipped. Drop
it and wait on the real condition instead: the new helper
ublk_wait_dev_ready_and_lock() waits on ublk_dev_ready() via
wait_var_event_interruptible(), woken from ublk_mark_io_ready(), then
re-checks it under ub->mutex, waiting again on regression, and returns
with the mutex held and readiness guaranteed.

Readiness becomes true in the same ub->mutex critical section that
clears the last queue's ->canceling, so END_USER_RECOVERY marks the
device LIVE and kicks the requeue list strictly after ->canceling
clears. The wait stays interruptible, so a server whose daemon died can
still be signalled out. For ublk_ctrl_start_dev() this replaces the
fail-fast -EINVAL on an F_BATCH ready->UNPREP regression with waiting
until the device is ready again.

The Linux kernel CVE team has assigned CVE-2026-68173 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 6.15 with commit 728cbac5fe219d3b8a21a0688a08f2b7f8aeda2b and fixed in 6.18.42 with commit 7dd26adf7e7d482af524e3a0cca4a81ef7c159d0
	Issue introduced in 6.15 with commit 728cbac5fe219d3b8a21a0688a08f2b7f8aeda2b and fixed in 7.1.6 with commit 8f188dd11a1c2ad94caeaee36ef68bb8221d4a12
	Issue introduced in 6.15 with commit 728cbac5fe219d3b8a21a0688a08f2b7f8aeda2b and fixed in 7.2-rc5 with commit 432a9b2780c0a01caf547bd1fc2fcf28aeb8d173
	Issue introduced in 6.14.6 with commit 42ea64e01c96e594fb4f80c54dfe4f934d008a6e

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-68173
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	drivers/block/ublk_drv.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/7dd26adf7e7d482af524e3a0cca4a81ef7c159d0
	https://git.kernel.org/stable/c/8f188dd11a1c2ad94caeaee36ef68bb8221d4a12
	https://git.kernel.org/stable/c/432a9b2780c0a01caf547bd1fc2fcf28aeb8d173