Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp3446231pxf; Mon, 29 Mar 2021 02:23:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxN3fbXzY3vGGb0phsmXdjKkoMIHGsQJEQaPgUZu+jBggsqklImi+tXOEHmYH8dcPM1XKMm X-Received: by 2002:a05:6402:4386:: with SMTP id o6mr28913384edc.307.1617009791598; Mon, 29 Mar 2021 02:23:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617009791; cv=none; d=google.com; s=arc-20160816; b=EcitG2mvCucMrAejDVi9TYMLfzB7uDLSlsMwR5iqwvLbIvVhJSgihurHgD0g/pVDnu Ccxe969oky1r5tWYUg6aL5riaLFjMKlOF1rHPBEql5cVP13HNnqzLnSzySK16y4VyGPN /UCT1KEEu8P+ThB8JWPb1C0vCtZqnsj8EYRUyUjuF7ASBm2ukwxL+2DCwDiwDXdMSGou l5mZ/I90s3rgoFtyFfail/f0KSmh0+2eddLwnZCyrptuCOC2PwZrqhzO2NctVdim3aEx yB2yB55ER6N2JHgg3YVqHXmPVxpaJIJJQX3oOBvdcU61i07Y1Bg17sHwOd42QgKo9hop q86A== 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=HuAVcMnrU28iAzLZkGAjPWoNhT7T9wAYUf6gRK0s59o=; b=1I5JOOERRTeOnA5BBghDHeE7cTqhcKoBOW/fF3kcgfee8kjaaZm6XYUk2UKYzH24Wr I5XCTGjxXq5ELAmhQd/bIwr92sR3A9vdsaQiuN7tklUQDT5i+s2oEpguFonAG75kg+cp hInDj7+/BTPeElt7+GzrzgLtamEXSPV7/7NEh4VXhGTcwNKTqdaL3GcQ6AePVC5VaEEi DdeXY+DtIBp4GP7/GYQmOJZgVHqtyoFMjphHKfDsaffKgDuR5kVPBBq0iNs28TijJGPB BbhsZ5h1uIVbn2eIkgq7YVk504Fhzo/f2nTsiDqDVVnFOERW5mxOtm+rIV/coBeedV5K 47VA== 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 ko14si12118999ejc.419.2021.03.29.02.22.45; Mon, 29 Mar 2021 02:23:11 -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 S231313AbhC2JVQ (ORCPT + 99 others); Mon, 29 Mar 2021 05:21:16 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:15381 "EHLO szxga06-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231297AbhC2JUr (ORCPT ); Mon, 29 Mar 2021 05:20:47 -0400 Received: from DGGEMS414-HUB.china.huawei.com (unknown [172.30.72.58]) by szxga06-in.huawei.com (SkyGuard) with ESMTP id 4F86TN53CJzlVjw; Mon, 29 Mar 2021 17:19:04 +0800 (CST) Received: from [10.174.176.202] (10.174.176.202) by DGGEMS414-HUB.china.huawei.com (10.3.19.214) with Microsoft SMTP Server id 14.3.498.0; Mon, 29 Mar 2021 17:20:35 +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> From: Zhang Yi Message-ID: Date: Mon, 29 Mar 2021 17:20:35 +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: <20210322172551.GJ31783@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/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? Thanks, Yi.