Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp1358422pxb; Thu, 16 Sep 2021 05:59:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJycE/KfrsKFlLTzCjiioBOMdWFVo6HUQumr+mrurfhDEtlBb+TpqYtKYmE7LDldUvU1mrii X-Received: by 2002:a6b:ef0d:: with SMTP id k13mr343325ioh.54.1631797157265; Thu, 16 Sep 2021 05:59:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631797157; cv=none; d=google.com; s=arc-20160816; b=Ddq0b5TLJSgwagi1J5+JMbRX18kBjLk4J9mOPidBgFujY2WIm5eDw5RyznhU0+XtXA mEYx+XWOaaWJT4LEtOh74rcppqPr94qEbq4Inv7GTAlkRt2Seu6SmoaoCl9PKo2Tmbfu +teZ1/Xxi5u1UWKP7os+9neggOlgqqhiBBPa9rlTagcxC/2tQ2X5Mf7Q9UP55dgj3gtQ +5MM6JhAui8BIsqpLSJMBESo9CfX8vzLHc36lnyCFpa39SycidapWeL1ld+YQs2up2Qi DNoSbReZqYByE6aG57YyOo1IYvRMJ7hYR+qSMNzGI0/voRNLjuMCKJhUHmk/GO6Z8vkK e3JQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=VkxCouwE2WY7RdAp45St2PLPkAh5kbIeowHiRnKSUjM=; b=LErLL56TbvuJilEO5rxZVYGeoEtSSgFx2QeaLLf4+La7VwRlhghjvvpSVD+qW/XwBc W8U7XtN7o0DCq7tUmwPnBSlHh343nYP3zMTvUK9f2hH98wCS8XZA4X+VP1Hpcn8ywlL7 3bCL81z0E884BBuGqnM09NOj7+gaut76hTYSPdF79PZVZMdmnYQ3PhH87V3CPcTcIZa/ psOLdvvMdVtXoMSrYkgvFOLpjfnBI6YGNs/ur+kJoOh55toXdF4zECFkmcTVAA6mBPPA sayO3QEv0llYp6pVYEDjttzcu/xZZBuj8JEazw3Kf54/kZObxanjRkmycZDmdCE/Ae6G FhaQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=eEWmgZJ1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k39si3095657jav.88.2021.09.16.05.59.05; Thu, 16 Sep 2021 05:59:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=eEWmgZJ1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239574AbhIPM7o (ORCPT + 99 others); Thu, 16 Sep 2021 08:59:44 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:56449 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239126AbhIPM7n (ORCPT ); Thu, 16 Sep 2021 08:59:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1631797102; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=VkxCouwE2WY7RdAp45St2PLPkAh5kbIeowHiRnKSUjM=; b=eEWmgZJ1+d5DG9D+6oOCTd0SsTwHAwyW9ig8cAVSq8MJyk6dQAEQe8bmbqmhbhcKXuPkDb gQxNMYG/4ryfuhVc8ZRi4ob+QRhNlWd+RndZK/j5aLnfe9QfhKzb7+6kbVV09UWjd/m1DT OvjzTuMthwcnhv+oH4Q8AqFfZxnL3z0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-304-zkGW37zANvSS2bNeBVDvlg-1; Thu, 16 Sep 2021 08:58:21 -0400 X-MC-Unique: zkGW37zANvSS2bNeBVDvlg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 56D7210247AB; Thu, 16 Sep 2021 12:58:20 +0000 (UTC) Received: from T590 (ovpn-12-89.pek2.redhat.com [10.72.12.89]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 681FD60C9F; Thu, 16 Sep 2021 12:58:12 +0000 (UTC) Date: Thu, 16 Sep 2021 20:58:24 +0800 From: Ming Lei To: Yu Kuai Cc: josef@toxicpanda.com, axboe@kernel.dk, hch@infradead.org, linux-block@vger.kernel.org, nbd@other.debian.org, linux-kernel@vger.kernel.org, yi.zhang@huawei.com Subject: Re: [patch v8 7/7] nbd: fix uaf in nbd_handle_reply() Message-ID: References: <20210916093350.1410403-1-yukuai3@huawei.com> <20210916093350.1410403-8-yukuai3@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210916093350.1410403-8-yukuai3@huawei.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 16, 2021 at 05:33:50PM +0800, Yu Kuai wrote: > There is a problem that nbd_handle_reply() might access freed request: > > 1) At first, a normal io is submitted and completed with scheduler: > > internel_tag = blk_mq_get_tag -> get tag from sched_tags > blk_mq_rq_ctx_init > sched_tags->rq[internel_tag] = sched_tag->static_rq[internel_tag] > ... > blk_mq_get_driver_tag > __blk_mq_get_driver_tag -> get tag from tags > tags->rq[tag] = sched_tag->static_rq[internel_tag] > > So, both tags->rq[tag] and sched_tags->rq[internel_tag] are pointing > to the request: sched_tags->static_rq[internal_tag]. Even if the > io is finished. > > 2) nbd server send a reply with random tag directly: > > recv_work > nbd_handle_reply > blk_mq_tag_to_rq(tags, tag) > rq = tags->rq[tag] > > 3) if the sched_tags->static_rq is freed: > > blk_mq_sched_free_requests > blk_mq_free_rqs(q->tag_set, hctx->sched_tags, i) > -> step 2) access rq before clearing rq mapping > blk_mq_clear_rq_mapping(set, tags, hctx_idx); > __free_pages() -> rq is freed here > > 4) Then, nbd continue to use the freed request in nbd_handle_reply > > Fix the problem by get 'q_usage_counter' before blk_mq_tag_to_rq(), > thus request is ensured not to be freed because 'q_usage_counter' is > not zero. > > Signed-off-by: Yu Kuai > --- > drivers/block/nbd.c | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c > index 69dc5eac9ad3..b3a47fc6237f 100644 > --- a/drivers/block/nbd.c > +++ b/drivers/block/nbd.c > @@ -825,6 +825,7 @@ static void recv_work(struct work_struct *work) > work); > struct nbd_device *nbd = args->nbd; > struct nbd_config *config = nbd->config; > + struct request_queue *q = nbd->disk->queue; > struct nbd_sock *nsock; > struct nbd_cmd *cmd; > struct request *rq; > @@ -835,7 +836,20 @@ static void recv_work(struct work_struct *work) > if (nbd_read_reply(nbd, args->index, &reply)) > break; > > + /* > + * Grab .q_usage_counter so request pool won't go away, then no > + * request use-after-free is possible during nbd_handle_reply(). > + * If queue is frozen, there won't be any inflight requests, we > + * needn't to handle the incoming garbage message. > + */ > + if (!percpu_ref_tryget(&q->q_usage_counter)) { > + dev_err(disk_to_dev(nbd->disk), "%s: no io inflight\n", > + __func__); > + break; > + } > + > cmd = nbd_handle_reply(nbd, args->index, &reply); > + percpu_ref_put(&q->q_usage_counter); > if (IS_ERR(cmd)) > break; The refcount needs to be grabbed when completing the request because the request may be completed from other code path, then the request pool will be freed from that code path when the request is referred. Thanks, Ming