Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp630590pxb; Tue, 2 Feb 2021 13:45:31 -0800 (PST) X-Google-Smtp-Source: ABdhPJzayZi7aO3juRZU3C85S1M2TLAUn4Mg8GgJbHfOpyZ+xXaYrRrTTePo0mYBgO/pavmgMYdp X-Received: by 2002:a17:906:7146:: with SMTP id z6mr18398ejj.159.1612302331661; Tue, 02 Feb 2021 13:45:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612302331; cv=none; d=google.com; s=arc-20160816; b=UPFO0GETF0yED+PjfBUlOj3O/5nMbeOs+RW520dJXllnXDcpM+xWnIiiDipl94lqIK av6GrS2rZ8/Zr5br5Z9zkxPL0ak60ohhTxL+kg4hr8K8sx13LXuelqgO+svQ/utjD0IF /BvdZtu3KCdioY8nYDIVIVDLiO6SuCf7DEMNdTV7vBLhiiAiqXrteyfyH3+3buHDyjqZ y1yJOIQB3N/3uzqb1KlCi/yfOHYAGfbs2ykRnfco1O001ByToGabL3owdqQxQmbYvEim uShyvIdgwuin9yuM4KKXao9m8VO+5Acw+ZFXlvMDBV9G1Dp+vEr8053988s2UbwVUE8i Htrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=ZsIDnX93Ye9XKUxuAey5xkuSQElZ/24W6t+1P8+uV7c=; b=VrDgwq9NWMuRJY6WX3LOb5gXyowtSwPfIhVCz+1CbvByXQSPDCqOsAe+Hi0ZQo6RH7 yiytPWg0kfBpVsTXkfdXpTZ6zvi58SC4a3LKaNYTUdzHmZChcW6034VtaoyOssavRCdH S7bVDbgxOtcnMuCtgoQKnDrQ27IfSqJ36PSdcYHWAS6jm2h3ieOGX70xl0T+B7jyhzSs AYkXkrjCEXJeSHX9bh8AnDBkRU2KPw8V+IHDNE+jgj4QjkFnoFeTsPtAoxn61zjc9wgt og0148lfxWUKbKVkWgYeE/koSv7r1keczALOojK1EzlNdqHetO6ttcDjbILp8TDUwzm1 JbaA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=IPnnFMvh; 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=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m20si2412edq.199.2021.02.02.13.45.06; Tue, 02 Feb 2021 13:45:31 -0800 (PST) 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=@linuxfoundation.org header.s=korg header.b=IPnnFMvh; 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=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232729AbhBBNm7 (ORCPT + 99 others); Tue, 2 Feb 2021 08:42:59 -0500 Received: from mail.kernel.org ([198.145.29.99]:34916 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232654AbhBBNkS (ORCPT ); Tue, 2 Feb 2021 08:40:18 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id F3FC464F51; Tue, 2 Feb 2021 13:39:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1612273177; bh=L1+JYUoKAgNua14sI2jrgxgg5JrqSalLKC6I1rdikLM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IPnnFMvh62VidyCOgFB/BUF2u9MXwWCAGpGPxb0lUlBu0cSkKA3K95+jmPVtVv4sK sp4/GiV/0o+Oj9br0q3hYm10a5FL/hEztBgHBV3FMT5U+qWznVkie4nnTJi75H/ad2 RKJtuvpNi26bTV+OBhyfyR1qMlVeTQ9YbjsMKgSs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Josef Bacik , Jens Axboe Subject: [PATCH 5.10 002/142] nbd: freeze the queue while were adding connections Date: Tue, 2 Feb 2021 14:36:05 +0100 Message-Id: <20210202132957.792200554@linuxfoundation.org> X-Mailer: git-send-email 2.30.0 In-Reply-To: <20210202132957.692094111@linuxfoundation.org> References: <20210202132957.692094111@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Josef Bacik commit b98e762e3d71e893b221f871825dc64694cfb258 upstream. When setting up a device, we can krealloc the config->socks array to add new sockets to the configuration. However if we happen to get a IO request in at this point even though we aren't setup we could hit a UAF, as we deref config->socks without any locking, assuming that the configuration was setup already and that ->socks is safe to access it as we have a reference on the configuration. But there's nothing really preventing IO from occurring at this point of the device setup, we don't want to incur the overhead of a lock to access ->socks when it will never change while the device is running. To fix this UAF scenario simply freeze the queue if we are adding sockets. This will protect us from this particular case without adding any additional overhead for the normal running case. Cc: stable@vger.kernel.org Signed-off-by: Josef Bacik Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman --- drivers/block/nbd.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/drivers/block/nbd.c +++ b/drivers/block/nbd.c @@ -1029,6 +1029,12 @@ static int nbd_add_socket(struct nbd_dev if (!sock) return err; + /* + * We need to make sure we don't get any errant requests while we're + * reallocating the ->socks array. + */ + blk_mq_freeze_queue(nbd->disk->queue); + if (!netlink && !nbd->task_setup && !test_bit(NBD_RT_BOUND, &config->runtime_flags)) nbd->task_setup = current; @@ -1067,10 +1073,12 @@ static int nbd_add_socket(struct nbd_dev nsock->cookie = 0; socks[config->num_connections++] = nsock; atomic_inc(&config->live_connections); + blk_mq_unfreeze_queue(nbd->disk->queue); return 0; put_socket: + blk_mq_unfreeze_queue(nbd->disk->queue); sockfd_put(sock); return err; }