In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
ublk: wait on ublk_dev_ready() instead of ub->completion<\/p>\n
ub->completion is only re-armed by a successful START_USER_RECOVERY. If
\nthe ublk server sends END_USER_RECOVERY without one – e.g. its START
\nfailed with -EBUSY and the error was ignored – the wait is satisfied by
\nthe stale completion of the previous recovery cycle, and the device is
\nmarked LIVE and the requeue list kicked while the FETCH stream is still
\nrunning and ubq->canceling is still set. The kick redispatches a
\npreviously requeued request, __ublk_queue_rq_common() sees ->canceling
\nand parks it again via __ublk_abort_rq(), and after the last FETCH
\nclears ->canceling nothing ever kicks the requeue list again: the
\nrequest is stranded there while holding its tag. If it is the flush
\nmachinery’s flush_rq, every subsequent fsync piles up in uninterruptible
\nsleep and teardown hangs on tag draining. This matches a report of a
\nlost PREFLUSH with ext4 on top of ublk after daemon crash recovery.<\/p>\n
ub->completion is an edge-triggered latch used as a proxy for the level
\ncondition “every queue has fetched all I\/O commands”, which can regress
\n(F_BATCH’s UNPREP, daemon death) and whose re-arm can be skipped. Drop
\nit and wait on the real condition instead: the new helper
\nublk_wait_dev_ready_and_lock() waits on ublk_dev_ready() via
\nwait_var_event_interruptible(), woken from ublk_mark_io_ready(), then
\nre-checks it under ub->mutex, waiting again on regression, and returns
\nwith the mutex held and readiness guaranteed.<\/p>\n
Readiness becomes true in the same ub->mutex critical section that
\nclears the last queue’s ->canceling, so END_USER_RECOVERY marks the
\ndevice LIVE and kicks the requeue list strictly after ->canceling
\nclears. The wait stays interruptible, so a server whose daemon died can
\nstill be signalled out. For ublk_ctrl_start_dev() this replaces the
\nfail-fast -EINVAL on an F_BATCH ready->UNPREP regression with waiting
\nuntil the device is ready again.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
ublk: wait on ublk_dev_ready() instead of ub->completion<\/p>\n
ub->completion is only re-armed by a successful START_USER_RECOVERY. If
\nt<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-5370","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/5370","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=5370"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=5370"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=5370"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}