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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BFA02C433FE for ; Fri, 24 Sep 2021 15:10:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5A8B76103C for ; Fri, 24 Sep 2021 15:10:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 5A8B76103C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id ACDC1900002; Fri, 24 Sep 2021 11:10:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A7CCB6B0072; Fri, 24 Sep 2021 11:10:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 96C80900002; Fri, 24 Sep 2021 11:10:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0247.hostedemail.com [216.40.44.247]) by kanga.kvack.org (Postfix) with ESMTP id 89BFE6B0071 for ; Fri, 24 Sep 2021 11:10:08 -0400 (EDT) Received: from smtpin39.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 21E5C8249980 for ; Fri, 24 Sep 2021 15:10:08 +0000 (UTC) X-FDA: 78622802496.39.8014D39 Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) by imf22.hostedemail.com (Postfix) with ESMTP id D27501907 for ; Fri, 24 Sep 2021 15:10:07 +0000 (UTC) Received: by mail-lf1-f52.google.com with SMTP id i4so41634282lfv.4 for ; Fri, 24 Sep 2021 08:10:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=co3PmFuKCIcHsj3pvj/B4T/OiVu8R01Eai9WLfmdlq8=; b=Bjrt0Rq7VPXOT3ycfENAR6ahmO3q368hhy2blwQAfkW0DIZ0c1pMsNlD5CtQitFJTx qH/NIP2KVRQW/48QpCjbwvdM2YGK5V44JFKsFMNOQYzI8lvqjfYmbaYASvSGl5nUmPKl gpWZXzPySuvTqio2vIERL174Lw61V3+jQaSsZp+2RSo8wixDGuZwkyd1Z1yYYf+DX/KA yieEqFqnNF9lzDF2iQXD0OqSPVwsQypESDyxq8xhrkCWNNgCfVfzoTHvx+8pe7uPAyYi +6kOP/AcGFryIPrl2D4MLYQ12sU1uO8ZInb9cYQqK0RZ88ePIrjJQTnFxxn1Cn5bfl1f 9QIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=co3PmFuKCIcHsj3pvj/B4T/OiVu8R01Eai9WLfmdlq8=; b=EIxjRmF62+h/hxd5rwyrB440t02powuooEVA4OCTnNZ84/QhysKeDE1iH8shGulGpz E/zyV5JtyyMNEyerzeF2gholbQhQsJk2cNen4dE9cclqjIr16NhjFqWtjMM5Dredp6Pf Kn99JtK8w4yRrKYv3NGZofgv7NEXYdrVMYF9aubyJ7Nm7AmHVyg776Ufws/GFSggbPZ0 FwmF34Q24i9iu0q6OaepZ4BNOtKLHyJM/wyX/w6yqqaAMoXUO8IvrC05Q2cCvtbybQch TXPjFXiykt+AidP5K5fyVsDHdGOwtPrWeSudqZc9Dsgr0f/I9COr2UYVkyybYUgrHfgW CIhw== X-Gm-Message-State: AOAM53243TjPteWDMi444w/Krvp0r/Ed4Nt3T3FLKi439LZUNv13DfyV 5+CET7IgKfwFw8eDtKMZlaZhlIyjTX+3vD72A0c= X-Google-Smtp-Source: ABdhPJz2O26v2suId4UxB1yb6OJ3KWGBnRKuzsLVAjf3+8tGobqu38rrwjzswt4hkyfnBvwFgETgvkj8GbimtYX5XTM= X-Received: by 2002:a05:6512:39d1:: with SMTP id k17mr220473lfu.390.1632496206181; Fri, 24 Sep 2021 08:10:06 -0700 (PDT) MIME-Version: 1.0 References: <20210907195226.14b1d22a07c085b22968b933@linux-foundation.org> <20210908030026.2dLZCmkE4%akpm@linux-foundation.org> In-Reply-To: From: Ryusuke Konishi Date: Sat, 25 Sep 2021 00:09:54 +0900 Message-ID: Subject: Re: [patch 136/147] nilfs2: use refcount_dec_and_lock() to fix potential UAF To: Matthew Wilcox Cc: Andrew Morton , linux-mm@kvack.org, mm-commits@vger.kernel.org, Zhen Lei , Linus Torvalds Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: D27501907 X-Stat-Signature: 9an87jkrujtg8h3bg6mf7gr9bs1ayomp Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Bjrt0Rq7; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf22.hostedemail.com: domain of konishi.ryusuke@gmail.com designates 209.85.167.52 as permitted sender) smtp.mailfrom=konishi.ryusuke@gmail.com X-HE-Tag: 1632496207-276548 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi, On Fri, Sep 24, 2021 at 9:13 PM Matthew Wilcox wrote: > > 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. The diagram is the same as that in the original patch by author, and I approved it without any discomfort because these five operations (nilfs_put_root() ~ spin_lock(); rb_erase(); spin_unlock() ~ kfree() ) are all done by CPU0. But, yeah, an example of a function call might have been written on the CPU1 side as well, for instance, a nilfs_lookup_root() call etc, to clarify the race issue the message explains.. Regards, Ryusuke Konishi