In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
rbd: eliminate a race in lock_dwork draining on unmap<\/p>\n
Given how rbd_lock_add_request() and rbd_img_exclusive_lock() are
\nwritten, lock_dwork may be (re)queued more than it’s actually needed:
\nfor example in case a new I\/O request comes in while we are in the
\nmiddle of rbd_acquire_lock() on behalf of another I\/O request. This is
\nexpected and with rbd_release_lock() preemptively canceling lock_dwork
\nis benign under normal operation.<\/p>\n
A more problematic example is maybe_kick_acquire():<\/p>\n
if (have_requests || delayed_work_pending(&rbd_dev->lock_dwork)) {
\n dout(“%s rbd_dev %p kicking lock_dworkn”, __func__, rbd_dev);
\n mod_delayed_work(rbd_dev->task_wq, &rbd_dev->lock_dwork, 0);
\n }<\/p>\n
It’s not unrealistic for lock_dwork to get canceled right after
\ndelayed_work_pending() returns true and for mod_delayed_work() to
\nrequeue it right there anyway. This is a classic TOCTOU race.<\/p>\n
When it comes to unmapping the image, there is an implicit assumption
\nof no self-initiated exclusive lock activity past the point of return
\nfrom rbd_dev_image_unlock() which unlocks the lock if it happens to be
\nheld. This unlock is assumed to be final and lock_dwork (as well as
\nall other exclusive lock tasks, really) isn’t expected to get queued
\nagain. However, lock_dwork is canceled only in cancel_tasks_sync()
\n(i.e. later in the unmap sequence) and on top of that the cancellation
\ncan get in effect nullified by maybe_kick_acquire(). This may result
\nin rbd_acquire_lock() executing after rbd_dev_device_release() and
\nrbd_dev_image_release() run and free and\/or reset a bunch of things.
\nOne of the possible failure modes then is a violated<\/p>\n
rbd_assert(rbd_image_format_valid(rbd_dev->image_format));<\/p>\n
in rbd_dev_header_info() which is called via rbd_dev_refresh() from
\nrbd_post_acquire_action().<\/p>\n
Redo exclusive lock task draining to provide saner semantics and try
\nto meet the assumptions around rbd_dev_image_unlock().<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
rbd: eliminate a race in lock_dwork draining on unmap<\/p>\n
Given how rbd_lock_add_request() and rbd_img_exclusive_lock() are
\nwritten, l<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-15081","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/15081","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=15081"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=15081"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=15081"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}