Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp3526773pxf; Mon, 22 Mar 2021 08:26:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxMGlJTFwCAWhzpCZKxLoIL/KUWdUieQZ7KWre/8iBMO07qsKSoVqyPRkiGGTGmjL4bzZ6/ X-Received: by 2002:a17:906:7806:: with SMTP id u6mr331296ejm.130.1616426795096; Mon, 22 Mar 2021 08:26:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616426795; cv=none; d=google.com; s=arc-20160816; b=fxThMvwwnUhbSphUKBJbFZhZ/T7BwwFEMK+w+dxyQBtqE+nuuoBjVHKPFyl6GVIQev WpaoC4eumJmxled1qW6qKWSUcCto4pm1k4Eh3pldeNzTQLIYDqX/uALBljtP4Gku4GLe ilFWGMy4aV5ddDklsqTwmzxjWjaW7gOh+DY2hd2ttHKwgqrXuhm/HUBVZwZXx4fxFP+5 9NLKJHBJVOyXxW0NmYny6hj8dwkgQ3Ai3la0SB1uid75xuq1b9TT4pFWbLjz9/njCfpV 5ixwbQYxYd164U8M47T/xXbPCvYajajPmOOIdrIu1+rGMFSXVN74syML0xMMQioVyWVZ L+lQ== 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 :mime-version:user-agent:date:message-id:subject:cc:to:from; bh=/AGYWWhuYSCvcd80NJmDGz6G7yctxSVaonu1lXnP34c=; b=JT4vU7pmA9e1xoewiLO7Mw8eotfMn7bknHWq1kGki8xC0lTQMwWwsoYnb4a9j0x+C1 1dfKQPnkYfc3ICkKxv3ZRE0xV6LySqXxsr007+BNIkX6QKaqF2Ee/qVQeuD4yrfoDz8a P3JUp+6a56qBpEHj9FzGG1UNAPZg1Y13TQuQhHLHUU6ZJskimjJ+glryf2GpiOi3E9fG 3YcUumTE1BC2pIhLXUMlAVYO1M4PiUoC93YIR0HiGtesJBtkAaocNLcHHGX1MvZlPZvB aqQSQhEOteWv051jaXLAu0Yx6F9rFB8/k/540/qspMqawf7MVFNesSFzyO1BZatkmoOv ye4Q== 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 t16si11873455edc.448.2021.03.22.08.26.03; Mon, 22 Mar 2021 08:26:35 -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 S229868AbhCVPY5 (ORCPT + 99 others); Mon, 22 Mar 2021 11:24:57 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:13658 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229665AbhCVPYg (ORCPT ); Mon, 22 Mar 2021 11:24:36 -0400 Received: from DGGEMS401-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4F3ysS6kvPznTVF; Mon, 22 Mar 2021 23:22:04 +0800 (CST) Received: from [10.174.176.202] (10.174.176.202) by DGGEMS401-HUB.china.huawei.com (10.3.19.201) with Microsoft SMTP Server id 14.3.498.0; Mon, 22 Mar 2021 23:24:24 +0800 From: Zhang Yi To: Jan Kara CC: "Theodore Y. Ts'o" , Ext4 Developers List , yangerkun Subject: [BUG && Question] question of SB_ACTIVE flag in ext4_orphan_cleanup() Message-ID: <8a6864dd-7e6c-5268-2b5b-1010f99d2a1b@huawei.com> Date: Mon, 22 Mar 2021 23:24:23 +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 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 Hi, Jan. 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? Thanks, Yi.