On 4/24/21 5:09 PM, Ming Lei wrote: > Terminating all pending commands can't avoid the issue wrt. request UAF, > so far blk_mq_tagset_wait_completed_request() is used for making sure > that all pending requests are really aborted. > > However, blk_mq_wait_for_tag_iter() still may return before > blk_mq_wait_for_tag_iter() is done because blk_mq_wait_for_tag_iter() > supposes all request reference is just done inside bt_tags_iter(), > especially .iter_rwsem and read rcu lock is added in bt_tags_iter(). Hi Ming, I think that we agree that completing a request from inside a tag iteration callback function may cause the request completion to happen after tag iteration has finished. This can happen because blk_mq_complete_request() may redirect completion processing to another CPU via an IPI. But can this mechanism trigger a use-after-free by itself? If request completion is redirected to another CPU, the request is still considered pending and request queue freezing won't complete. Request queue freezing will only succeed after __blk_mq_free_request() has been called because it is __blk_mq_free_request() that calls blk_queue_exit(). In other words, do we really need the new blk_mq_complete_request_locally() function? Did I perhaps miss something? Thanks, Bart.
