From patchwork Thu Mar 4 14:01:40 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: William Breathitt Gray X-Patchwork-Id: 1447362 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4DrsxK26L2z9sWc; Fri, 5 Mar 2021 01:01:57 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1lHoY5-0006hX-6J; Thu, 04 Mar 2021 14:01:53 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1lHoY4-0006h3-7z for kernel-team@lists.ubuntu.com; Thu, 04 Mar 2021 14:01:52 +0000 Received: from mail-pj1-f69.google.com ([209.85.216.69]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1lHoY3-0007Tw-S2 for kernel-team@lists.ubuntu.com; Thu, 04 Mar 2021 14:01:52 +0000 Received: by mail-pj1-f69.google.com with SMTP id e11so6800947pjj.8 for ; Thu, 04 Mar 2021 06:01:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=FCxqP4n8FyP3Y392+SWN0fe+WAziVSIj0ksA9BuGD0U=; b=jVL19SEbDrTITap94PN//qcO5P+cpPKjenF0Uo/EhTNsRDMPt1GDe6Kvj7g0SJYnoE Lzhs5RoPeQbWGxQMaC2VuB2aeVRxDkQBdYNqyk9Mkp51S2M7P54zyEzQxr2b8BkFiPRT Vz/KTkET7sBVtE0WTI7f0Niy2mCmU65csfg1rpzHC4UCDkSzmN4Tur0SLcf7npCHU+Nt HKsfrEtjbbS6WaOJcNvhMc/gSgUVl/vaNoyGc67A8E1epEWsebgrPDyYn86GfA1ttyqb ATlnlHVJFcwkjwKSHirxqNufZJn7qBRCeJu7a8jj5gLjrIn2A1hQiUnuqPsNO+2WYNAi Zyhw== X-Gm-Message-State: AOAM532OxIjhnrY3GmNJi22u38EN/ncb2CdrUqr0DiEBYB/iObNiXWC6 21n4zci/PGRnazzJHBVgeAbpE7LZSAl6pMbsieNP3gqcGEG/7ugsE8mShZpwGmGL1MLsyGltvye aA5cmBctqzBYyvpOtI+et6dSI37PWuVakJYrsnuy6Lw== X-Received: by 2002:aa7:8703:0:b029:1ee:ec64:981f with SMTP id b3-20020aa787030000b02901eeec64981fmr3895397pfo.5.1614866510254; Thu, 04 Mar 2021 06:01:50 -0800 (PST) X-Google-Smtp-Source: ABdhPJxDTDZviPNkGmgOQ82L1p5HiBnyHWNe7PeZP6nqRonDUetTYuVn2rZc2HrsOHOgEBoDGzZ4uA== X-Received: by 2002:aa7:8703:0:b029:1ee:ec64:981f with SMTP id b3-20020aa787030000b02901eeec64981fmr3895359pfo.5.1614866509822; Thu, 04 Mar 2021 06:01:49 -0800 (PST) Received: from localhost.localdomain (113x37x72x20.ap113.ftth.ucom.ne.jp. [113.37.72.20]) by smtp.gmail.com with ESMTPSA id w128sm28455047pfw.86.2021.03.04.06.01.48 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Mar 2021 06:01:49 -0800 (PST) From: William Breathitt Gray To: kernel-team@lists.ubuntu.com Subject: [SRU][CVE-2021-3348][B][PATCH 1/1] nbd: freeze the queue while we're adding connections Date: Thu, 4 Mar 2021 09:01:40 -0500 Message-Id: <20210304140140.7594-3-william.gray@canonical.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20210304140140.7594-1-william.gray@canonical.com> References: <20210304140140.7594-1-william.gray@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Josef Bacik 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 CVE-2021-3348 (backported from commit b98e762e3d71e893b221f871825dc64694cfb258) [ vilhelmgray: context adjustment ] Signed-off-by: William Breathitt Gray --- drivers/block/nbd.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c index aa78bd1b7547..eb5c4b110174 100644 --- a/drivers/block/nbd.c +++ b/drivers/block/nbd.c @@ -952,6 +952,12 @@ static int nbd_add_socket(struct nbd_device *nbd, unsigned long arg, 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_BOUND, &config->runtime_flags)) nbd->task_setup = current; @@ -990,10 +996,12 @@ static int nbd_add_socket(struct nbd_device *nbd, unsigned long arg, 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; }