From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 84096C433FE for ; Fri, 24 Sep 2021 12:13:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0548961107 for ; Fri, 24 Sep 2021 12:13:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0548961107 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 1627F6B0071; Fri, 24 Sep 2021 08:13:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1117F6B0072; Fri, 24 Sep 2021 08:13:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 000E7900002; Fri, 24 Sep 2021 08:13:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0147.hostedemail.com [216.40.44.147]) by kanga.kvack.org (Postfix) with ESMTP id E56B26B0071 for ; Fri, 24 Sep 2021 08:13:21 -0400 (EDT) Received: from smtpin35.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 95FDA348D0 for ; Fri, 24 Sep 2021 12:13:21 +0000 (UTC) X-FDA: 78622357002.35.875A4A4 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf04.hostedemail.com (Postfix) with ESMTP id E23EF50000B2 for ; Fri, 24 Sep 2021 12:13:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=GgW0GvnokLjku9AJnSodEihBkOdE/1jhYJQC0NGl+sg=; b=vkWGfN9waykNU3+C1QXNmY2r1d eK9sK8ZliSadEtJBpyX8/enPHhKH/ZhYNCGLVPkStdQQlEBzIAf4w3nMUTJ58rJoIuJN8Boq+IzWF 3M5c0gA+wlWn9y+BxGgZPoo3kstXAug19JWdVAcCiQxxXw396HX43hiyHnOfo3tchjwML7UMcTSEe 7KRMCREizEDkUpzksvx1Io8O+R6OQKW5UwC9/bVT/L4mArGcc4tXyLOc1meH5Pci2weJz413RUBe1 Ry/Gw4AJnSX+zImLfOetCkoBK1Kcl9Xll10TMhQ2HkPSlSAFbSAOYdNSxA7N7CBaWT6ir+6Jprv65 s75JgFWQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mTk4B-007ALy-Q1; Fri, 24 Sep 2021 12:12:51 +0000 Date: Fri, 24 Sep 2021 13:12:35 +0100 From: Matthew Wilcox To: Andrew Morton Cc: konishi.ryusuke@gmail.com, linux-mm@kvack.org, mm-commits@vger.kernel.org, thunder.leizhen@huawei.com, torvalds@linux-foundation.org Subject: Re: [patch 136/147] nilfs2: use refcount_dec_and_lock() to fix potential UAF Message-ID: References: <20210907195226.14b1d22a07c085b22968b933@linux-foundation.org> <20210908030026.2dLZCmkE4%akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210908030026.2dLZCmkE4%akpm@linux-foundation.org> X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: E23EF50000B2 X-Stat-Signature: uds36cepn51xaao43htepkdj6ct7hfi7 Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=vkWGfN9w; spf=none (imf04.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-HE-Tag: 1632485599-374747 X-Bogosity: Ham, tests=bogofilter, spamicity=0.001593, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Sep 07, 2021 at 08:00:26PM -0700, Andrew Morton wrote: > From: Zhen Lei > Subject: nilfs2: use refcount_dec_and_lock() to fix potential UAF > > When the refcount is decreased to 0, the resource reclamation branch is > entered. Before CPU0 reaches the race point (1), CPU1 may obtain the > spinlock and traverse the rbtree to find 'root', see nilfs_lookup_root(). > Although CPU1 will call refcount_inc() to increase the refcount, it is > obviously too late. CPU0 will release 'root' directly, CPU1 then accesses > 'root' and triggers UAF. > > Use refcount_dec_and_lock() to ensure that both the operations of decrease > refcount to 0 and link deletion are lock protected eliminates this risk. > > CPU0 CPU1 > nilfs_put_root(): > <-------- (1) > spin_lock(&nilfs->ns_cptree_lock); > rb_erase(&root->rb_node, &nilfs->ns_cptree); > spin_unlock(&nilfs->ns_cptree_lock); > > kfree(root); > <-------- use-after-free I don't know where this happened, but the leading whitespace has been eaten at some point, making this description of the race completely unreadable as everything appears to be done by CPU 0.