Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp83242pxf; Tue, 30 Mar 2021 20:17:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwp/FOr5gQ7BuS32ga0hiiV1BlfLV5qAxWOzLxDW2pLfRLWrnlTXaDgvdSDhV3P72i9iJu3 X-Received: by 2002:a50:cdd1:: with SMTP id h17mr1095216edj.178.1617160651584; Tue, 30 Mar 2021 20:17:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617160651; cv=none; d=google.com; s=arc-20160816; b=NG2CNYbuXTxRYuR8bIK7KOFv1f1pZm6OPV0W6Z2BXwmW+K2Gl3UJYEbVEBq1lDSbse lzWRlNUHuZnb8Nnnvf9W1MrEmsz6Ob+02LkJUiNNPIGtwU+Xz8kL/mxZFqzgm0Q7hTZ6 jwGKrk9oCX0feUHn+gRerpwKmqbTLyaF6HBTWnD5viGhxBGsKzd+KKzKUBB9pyOI3LpC ihXur2kFrYWWAtzIEZAoGQYzddVPtkGv4C5dwm1KEaDyMg70Gs/Z0ymWel9CbGD1pAsR IER/mGh0PxjswsEHKnpNn2D3vBuuyhM7aMfE5iOppHe00MkpL80XnWUd1H30L+rLp8sn dDug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=EEjW4Cyg/htk9yILgToDgWCBUoH4RsrjhM7jCbgwaXU=; b=dTxDXyG0eVNHru2eDc+R+wzeWSgclRM5fyNnj4PjknVmf8PmnnkXB9qgkEIhmgq3Co XIj8XV5S7sj83QhoWnbHK/1KXpJIBKrxFfbYgLtcq4vvDA+/f93c6TICSqJI7njTSwrI UM3yJG11hl4wUqJgEu4mvhc4UOrsqNSk2uW0TpSzZ4cYRsGP6QneLuNY6tSt62F/xiSB CkdlVrBoHpzOFyuiBwe9lXYV5adHw3uZ7ARQUKfTwlWM17CsL4qjSU+BwfIQPfhXP1wU 1dIyX5OVReuw/aBRpStJeagaREhxc9LRmx4JeOr7DMuvJu6AidULF54WfnOYLaOX6uUA vqcA== 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 g7si681753edb.286.2021.03.30.20.16.57; Tue, 30 Mar 2021 20:17:31 -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 S233117AbhCaDLe (ORCPT + 99 others); Tue, 30 Mar 2021 23:11:34 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:14969 "EHLO szxga05-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232874AbhCaDLW (ORCPT ); Tue, 30 Mar 2021 23:11:22 -0400 Received: from DGGEMS405-HUB.china.huawei.com (unknown [172.30.72.58]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4F9B9m14MFzyNMg; Wed, 31 Mar 2021 11:09:16 +0800 (CST) Received: from [10.174.176.202] (10.174.176.202) by DGGEMS405-HUB.china.huawei.com (10.3.19.205) with Microsoft SMTP Server id 14.3.498.0; Wed, 31 Mar 2021 11:11:11 +0800 Subject: Re: [BUG && Question] question of SB_ACTIVE flag in ext4_orphan_cleanup() To: Jan Kara CC: "Theodore Y. Ts'o" , Ext4 Developers List , yangerkun , References: <8a6864dd-7e6c-5268-2b5b-1010f99d2a1b@huawei.com> <20210322172551.GJ31783@quack2.suse.cz> <20210330150229.GC30749@quack2.suse.cz> From: Zhang Yi Message-ID: <99cce8ca-e4a0-7301-840f-2ace67c551f3@huawei.com> Date: Wed, 31 Mar 2021 11:11:10 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: <20210330150229.GC30749@quack2.suse.cz> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.176.202] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On 2021/3/30 23:02, Jan Kara wrote: > On Mon 29-03-21 17:20:35, Zhang Yi wrote: >> On 2021/3/23 1:25, Jan Kara wrote: >>> Hi! >>> >>> On Mon 22-03-21 23:24:23, Zhang Yi wrote: >>>> We find a use after free problem when CONFIG_QUOTA is enabled, the detail of >>>> this problem is below. >>>> >>>> mount_bdev() >>>> ext4_fill_super() >>>> sb->s_root = d_make_root(root); >>>> ext4_orphan_cleanup() >>>> sb->s_flags |= SB_ACTIVE; <--- 1. mark sb active >>>> ext4_orphan_get() >>>> ext4_truncate() >>>> ext4_block_truncate_page() >>>> mark_buffer_dirty <--- 2. dirty inode >>>> iput() >>>> iput_final <--- 3. put into lru list >>>> ext4_mark_recovery_complete <--- 4. failed and return error >>>> sb->s_root = NULL; >>>> deactivate_locked_super() >>>> kill_block_super() >>>> generic_shutdown_super() >>>> <--- 5. did not evict_inodes >>>> put_super() >>>> __put_super() >>>> <--- 6. put super block >>>> >>>> Because of the truncated inodes was dirty and will write them back later, it >>>> will trigger use after free problem. Now the question is why we need to set >>>> SB_ACTIVE bit when enable CONFIG_QUOTA below? >>>> >>>> #ifdef CONFIG_QUOTA >>>> /* Needed for iput() to work correctly and not trash data */ >>>> sb->s_flags |= SB_ACTIVE; >>>> >>>> This code was merged long long ago in v2.6.6, IIUC, it may not affect >>>> the quota statistics it we evict inode directly in the last iput. >>>> In order to slove this UAF problem, I'm not sure is there any side effect >>>> if we just remove this code, or remove SB_ACTIVE and call evict_inodes() >>>> in the error path of ext4_fill_super(). >>>> >>>> Could you give some suggestions? >>> >>> That's a very good question. I do remember that I've added this code back >>> then because otherwise orphan cleanup was loosing updates to quota files. >>> But you're right that now I don't see how that could be happening and it >>> would be nice if we could get rid of this hack (and even better if it also >>> fixes the problem you've found). I guess I'll just try and test this change >>> with various quota configurations to see whether something still breaks or >>> not. Thanks report! >>> >> >> Thanks for taking time to look at this, is this change OK under your various >> quota test cases? > > Yes, I did tests both with journalled quotas and with ext4 quota feature > and the quota accounting was correct after orphan recovery. So just > removing the SB_ACTIVE setting is fine AFAICT. Will you send a patch or > should I do it? > Thanks for testing this change, I will send a patch. Yi.