From: Ming Lei <ming.lei@redhat.com>
To: Yu Kuai <yukuai3@huawei.com>
Cc: axboe@kernel.dk, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org, yi.zhang@huawei.com
Subject: Re: [PATCH RFC] blk-mq: fix potential uaf for 'queue_hw_ctx'
Date: Fri, 25 Feb 2022 10:40:07 +0800 [thread overview]
Message-ID: <YhhBh0ehPjdARU5h@T590> (raw)
In-Reply-To: <20220223112601.2902761-1-yukuai3@huawei.com>
On Wed, Feb 23, 2022 at 07:26:01PM +0800, Yu Kuai wrote:
> blk_mq_realloc_hw_ctxs() will free the 'queue_hw_ctx'(e.g. undate
> submit_queues through configfs for null_blk), while it might still be
> used from other context(e.g. switch elevator to none):
>
> t1 t2
> elevator_switch
> blk_mq_unquiesce_queue
> blk_mq_run_hw_queues
> queue_for_each_hw_ctx
> // assembly code for hctx = (q)->queue_hw_ctx[i]
> mov 0x48(%rbp),%rdx -> read old queue_hw_ctx
>
> __blk_mq_update_nr_hw_queues
> blk_mq_realloc_hw_ctxs
> hctxs = q->queue_hw_ctx
> q->queue_hw_ctx = new_hctxs
> kfree(hctxs)
> movslq %ebx,%rax
> mov (%rdx,%rax,8),%rdi ->uaf
>
> This problem was found by code review, and I comfirmed that the concurrent
> scenarios do exist(specifically 'q->queue_hw_ctx' can be changed during
> blk_mq_run_hw_queues), however, the uaf problem hasn't been repoduced yet
> without hacking the kernel.
>
> Sicne the queue is freezed in __blk_mq_update_nr_hw_queues, fix the
> problem by protecting 'queue_hw_ctx' through rcu where it can be accessed
> without grabbing 'q_usage_counter'.
>
> Signed-off-by: Yu Kuai <yukuai3@huawei.com>
> ---
> block/blk-mq.c | 8 +++++++-
> include/linux/blk-mq.h | 2 +-
> include/linux/blkdev.h | 13 ++++++++++++-
> 3 files changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index 6c59ffe765fd..79367457d555 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -3955,7 +3955,13 @@ static void blk_mq_realloc_hw_ctxs(struct blk_mq_tag_set *set,
> if (hctxs)
> memcpy(new_hctxs, hctxs, q->nr_hw_queues *
> sizeof(*hctxs));
> - q->queue_hw_ctx = new_hctxs;
> +
> + rcu_assign_pointer(q->queue_hw_ctx, new_hctxs);
> + /*
> + * Make sure reading the old queue_hw_ctx from other
> + * context concurrently won't trigger uaf.
> + */
> + synchronize_rcu();
> kfree(hctxs);
> hctxs = new_hctxs;
> }
> diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
> index d319ffa59354..edcf8ead76c6 100644
> --- a/include/linux/blk-mq.h
> +++ b/include/linux/blk-mq.h
> @@ -918,7 +918,7 @@ static inline void *blk_mq_rq_to_pdu(struct request *rq)
>
> #define queue_for_each_hw_ctx(q, hctx, i) \
> for ((i) = 0; (i) < (q)->nr_hw_queues && \
> - ({ hctx = (q)->queue_hw_ctx[i]; 1; }); (i)++)
> + ({ hctx = queue_hctx((q), i); 1; }); (i)++)
>
> #define hctx_for_each_ctx(hctx, ctx, i) \
> for ((i) = 0; (i) < (hctx)->nr_ctx && \
> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> index 3bfc75a2a450..2018a4dd2028 100644
> --- a/include/linux/blkdev.h
> +++ b/include/linux/blkdev.h
> @@ -354,7 +354,7 @@ struct request_queue {
> unsigned int queue_depth;
>
> /* hw dispatch queues */
> - struct blk_mq_hw_ctx **queue_hw_ctx;
> + struct blk_mq_hw_ctx __rcu **queue_hw_ctx;
> unsigned int nr_hw_queues;
>
> /*
> @@ -622,6 +622,17 @@ static inline bool queue_is_mq(struct request_queue *q)
> return q->mq_ops;
> }
>
> +static inline struct blk_mq_hw_ctx *queue_hctx(struct request_queue *q, int id)
> +{
> + struct blk_mq_hw_ctx *hctx;
> +
> + rcu_read_lock();
> + hctx = *(rcu_dereference(q->queue_hw_ctx) + id);
> + rcu_read_unlock();
> +
> + return hctx;
> +}
queue_hctx() should be moved into linux/blk-mq.h, otherwise feel free to
add:
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Also it should be fine to implement queue_for_each_hw_ctx() as list, then we
can avoid the allocation for q->queue_hw_ctx without extra cost. I will work
toward that direction for improving the code.
Thanks,
Ming
next prev parent reply other threads:[~2022-02-25 2:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-23 11:26 [PATCH RFC] blk-mq: fix potential uaf for 'queue_hw_ctx' Yu Kuai
2022-02-23 14:30 ` Ming Lei
2022-02-24 1:29 ` yukuai (C)
2022-02-24 2:15 ` Ming Lei
2022-02-24 2:43 ` yukuai (C)
2022-02-25 2:40 ` Ming Lei [this message]
2022-02-25 3:15 ` yukuai (C)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YhhBh0ehPjdARU5h@T590 \
--to=ming.lei@redhat.com \
--cc=axboe@kernel.dk \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=yi.zhang@huawei.com \
--cc=yukuai3@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox