Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp4456550pxv; Tue, 29 Jun 2021 07:28:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxhNLa1MAVeRgrWV1yXcxwpms0oQ5YYPFg8vQ1ieBu8lTXmJGxrvAv+aRqikgfqUaESjXRf X-Received: by 2002:a05:6402:498:: with SMTP id k24mr22471126edv.25.1624976892310; Tue, 29 Jun 2021 07:28:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624976892; cv=none; d=google.com; s=arc-20160816; b=Kpj2NYNsV8VpsZ6rYi5w8FP54tcwXqbX3+wklS8h0MlY+/UUQmN2czVbPl67kcCq2g I+faVrel3CkT0qGFBg5rM8fS4bRhW1bU3RZARkfj342cx1K6oFSf4uVq/vFBwABqY1BK iqm4Ck6zojiDUotjUl9noe76gg3L6dNFUNQYg8e1p7VYeUR/JMZJGZARXb4SGjKgGa+1 27i779Bsmc/SPF5wDqRjCRo1NzEeQy5DD7ym27O4Tsj5Ap/xqC/UYb/8IcdFPjVf53nE FQqdwFvDlkgaBSSr3N2yXvTZuWp8fVhCDEqZBRanyWVia+9Egk+pwKJbkCF4hf1Fm587 tRfg== 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 :references:in-reply-to:message-id:date:subject:cc:to:from; bh=+fagPPBpeg/WP5oyUzfNwhszCj9LsU3T9XeFVs0VeZ0=; b=wTjTWU92ZUrBFP6lAshxZI8O8oIW92ydjzSS8dy7MQLsPO4AovaocVsUTe89jxUbsu +RZe/mbeZxeVsE4rY9yv2gLIasJQuPNULxOq/1C6huulcg4B5P6Fa8icqXjH9AONq07k 6O3yiPXrn831ED5J6RPIF9CqGF1yjP5z1Ksw+CuYDhBtMD17aMKCT2YNGIjGnQKAgVVU xn/oeOUEsp2TwI6Ljjtg223ISAx6rMv9XFeA0GZ/9TPvjCisUIuOKJ4AX27zxEtJv25T 3ciSuLMNx3Zyge8o+nHSa1/hf32OGGaX+qCpxB7s22/5G/eDsmCQbQ3XGWNdOHSZXHsg m65w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r15si198910edp.304.2021.06.29.07.27.42; Tue, 29 Jun 2021 07:28:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234355AbhF2O36 (ORCPT + 99 others); Tue, 29 Jun 2021 10:29:58 -0400 Received: from szxga01-in.huawei.com ([45.249.212.187]:6023 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233941AbhF2O3x (ORCPT ); Tue, 29 Jun 2021 10:29:53 -0400 Received: from dggeme754-chm.china.huawei.com (unknown [172.30.72.55]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4GDmrY1gLvzXmVb; Tue, 29 Jun 2021 22:22:05 +0800 (CST) Received: from huawei.com (10.175.127.227) by dggeme754-chm.china.huawei.com (10.3.19.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Tue, 29 Jun 2021 22:27:23 +0800 From: Ye Bin To: , , , , CC: Ye Bin Subject: [PATCH 2/2] ext4: Fix potential uas-after-free about sbi->s_mmp_tsk when kmmpd kthread exit before set sbi->s_mmp_tsk Date: Tue, 29 Jun 2021 22:36:03 +0800 Message-ID: <20210629143603.2166962-3-yebin10@huawei.com> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210629143603.2166962-1-yebin10@huawei.com> References: <20210629143603.2166962-1-yebin10@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.175.127.227] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To dggeme754-chm.china.huawei.com (10.3.19.100) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Now sbi->s_mmp_tsk is created with kthread_run, then kmmpd maybe already running and even exit as exception. Even though we set sbi->s_mmp_tsk with NULL before kmmpd kthread exit, but "sbi->s_mmp_tsk=kthread_run(XX)" may set after set with NULL. mount kmmpd | | |-call kthread_run | | |-kmmpd runing | |-kmmpd exit sbi->s_mmp_tsk=NULL | | |-kthread_run return | | and set sbi->s_mmp_tsk | | | |-then we get wild ptr"sbi->s_mmp_tsk" and later trigger UAF This patch is base on previous "ext4: Fix use-after-free about sbi->s_mmp_tsk". Previous patch ensure kmmpd kthread exit by itself will set sbi->s_mmp_tsk with NULL. We can create kthread first, and then wakeup kmmpd kthread later. Signed-off-by: Ye Bin --- fs/ext4/mmp.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/fs/ext4/mmp.c b/fs/ext4/mmp.c index fc18a8c205c7..6ec1ea182cc0 100644 --- a/fs/ext4/mmp.c +++ b/fs/ext4/mmp.c @@ -394,16 +394,18 @@ int ext4_multi_mount_protect(struct super_block *sb, /* * Start a kernel thread to update the MMP block periodically. */ - EXT4_SB(sb)->s_mmp_tsk = kthread_run(kmmpd, sb, "kmmpd-%.*s", - (int)sizeof(mmp->mmp_bdevname), - bdevname(bh->b_bdev, - mmp->mmp_bdevname)); + EXT4_SB(sb)->s_mmp_tsk = kthread_create(kmmpd, sb, "kmmpd-%.*s", + (int)sizeof(mmp->mmp_bdevname), + bdevname(bh->b_bdev, + mmp->mmp_bdevname)); + if (IS_ERR(EXT4_SB(sb)->s_mmp_tsk)) { EXT4_SB(sb)->s_mmp_tsk = NULL; ext4_warning(sb, "Unable to create kmmpd thread for %s.", sb->s_id); goto failed; } + wake_up_process(EXT4_SB(sb)->s_mmp_tsk); return 0; -- 2.31.1