Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp524580pxf; Thu, 8 Apr 2021 07:54:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy2p5B0hhSyis0c80u+6dt0kVWXyvLLAI7gD5eNrXABrGF5wDKQaZhb4fE0GWhyG9dZryod X-Received: by 2002:a17:902:8f8d:b029:e7:4a2f:1950 with SMTP id z13-20020a1709028f8db02900e74a2f1950mr7970559plo.77.1617893647897; Thu, 08 Apr 2021 07:54:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617893647; cv=none; d=google.com; s=arc-20160816; b=VHHbm0kf96+Apyo65vV+MB0kVw64sBts6JIGivA6HH6DhoVKlUxsfeYSFjmDcXzWMR Otk3wh2hk7ZY5fJn7QXeOwKm+Js68ZsYZZIrZQ017TMEhUsYuNsID6P5RuzBFvPxJ24D zr6L6H5r6bNfYoFWAf7kjwalhIQRNc0EKokJMyfXBkL2GDFOBCbqka4hUqtKt8kNKwct /8MO/5tPz5JCCDVp8J7o2T9vEowLJoNltKiGMWF8rOIYonx5wWmGoLo62XJgmV4pjccT Uo+wnZwN4yjdKW80tV0Kcf9qaGMKZYdCjK552cC9VHHRyHV2Vtsmu7uhoVnfwdVtjmHh mtPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=bSPv8US+aoI3SUqLHInI2ndEVJJSKGnb4ZP3z6zCRlo=; b=QPiRdJONcun6AvuoexosVmaouQC5KSZpwEXVV9bmJsE8CBt3/INAZT3GWAPGX0tCoS P1O5aOfPDUxSl57eyXRGk3IATnylmgE1YL2sguyX6tQjWBDfvwFRgj0OYnOcCrOhlPhg Ozb2nSTofLqz+uAGMA8y1G5wE8u5lXpH34zMec6b6iYNJUpe55zZJNP0SwXnA04U4Qmm Nb93TgqIXl4ld1tX7Cp82t9kUYA3W/ttLuo2PQhkpTCYuW7zntlSD1gS7/aOG3PNANRz SxBbL4cI7Zlzq9+quvRJ4l5pMY5J8I0ahReiOlmSJgatwfKCK4sIY+/ugMUMNgtwBX1/ NoDA== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o7si9740382plg.332.2021.04.08.07.53.52; Thu, 08 Apr 2021 07:54:07 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231911AbhDHOxw (ORCPT + 99 others); Thu, 8 Apr 2021 10:53:52 -0400 Received: from mx2.suse.de ([195.135.220.15]:58046 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231893AbhDHOxv (ORCPT ); Thu, 8 Apr 2021 10:53:51 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 6E01CB124; Thu, 8 Apr 2021 14:53:39 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id EF3D31F2B77; Thu, 8 Apr 2021 16:53:38 +0200 (CEST) Date: Thu, 8 Apr 2021 16:53:38 +0200 From: Jan Kara To: Zhang Yi Cc: Jan Kara , linux-ext4@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, yukuai3@huawei.com Subject: Re: [PATCH 3/3] ext4: add rcu to prevent use after free when umount filesystem Message-ID: <20210408145338.GF3271@quack2.suse.cz> References: <20210408113618.1033785-1-yi.zhang@huawei.com> <20210408113618.1033785-4-yi.zhang@huawei.com> <20210408135603.GD3271@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Thu 08-04-21 22:38:08, Zhang Yi wrote: > On 2021/4/8 21:56, Jan Kara wrote: > > On Thu 08-04-21 19:36:18, Zhang Yi wrote: > >> There is a race between bdev_try_to_free_page() and > >> jbd2_journal_destroy() that could end up triggering a use after free > >> issue about journal. > >> > >> drop cache umount filesystem > >> bdev_try_to_free_page() > >> get journal > >> jbd2_journal_try_to_free_buffers() ext4_put_super() > >> kfree(journal) > >> access journal <-- lead to UAF > >> > >> The above race also could happens between the bdev_try_to_free_page() > >> and the error path of ext4_fill_super(). This patch avoid this race by > >> add rcu protection around accessing sbi->s_journal in > >> bdev_try_to_free_page() and destroy the journal after an rcu grace > >> period. > >> > >> Signed-off-by: Zhang Yi > > > > OK, I see the problem. But cannot the use-after-free happen even for the > > superblock itself (e.g., EXT4_SB(sb)->s_journal dereference)? I don't see > > anything preventing that as blkdev_releasepage() just shamelessly does: > > > > super = BDEV_I(page->mapping->host)->bdev.bd_super > > > Hi, Jan. > > I checked the superblock. In theory, the bdev_try_to_free_page() is invoked > with page locked, the umount process will wait the page unlock on > kill_block_super()->..->kill_bdev()->truncate_inode_pages_range() before free > superblock, so I guess the use-after-free problem couldn't happen in general. > But I think it's fragile and may invalidate if the bdev has more than one > operners(__blkdev_put() call kill_bdev only if bd_openers becomes zero)? Yes, kill_bdev() is only called when bd_openers drops to 0 but there can be other processes having the bdev open (non-exclusively). Honza -- Jan Kara SUSE Labs, CR