Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 5 Aug 2022 15:07:26 +0200
From:   Lukas Czerner <lczerner@redhat.com>
To:     Baokun Li <libaokun1@huawei.com>
Cc:     linux-ext4@vger.kernel.org, tytso@mit.edu,
        adilger.kernel@dilger.ca, jack@suse.cz, ritesh.list@gmail.com,
        enwlinux@gmail.com, linux-kernel@vger.kernel.org,
        yi.zhang@huawei.com, yebin10@huawei.com, yukuai3@huawei.com
Subject: Re: [PATCH] ext4: fix null-ptr-deref in ext4_write_info
Message-ID: <20220805130726.a3otpkbrjv3ijumd@fedora>
References: <20220805123947.565152-1-libaokun1@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220805123947.565152-1-libaokun1@huawei.com>
Precedence: bulk

On Fri, Aug 05, 2022 at 08:39:47PM +0800, Baokun Li wrote:
> I caught a null-ptr-deref bug as follows:
> ==================================================================
> KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f]
> CPU: 1 PID: 1589 Comm: umount Not tainted 5.10.0-02219-dirty #339
> RIP: 0010:ext4_write_info+0x53/0x1b0
> [...]
> Call Trace:
>  dquot_writeback_dquots+0x341/0x9a0
>  ext4_sync_fs+0x19e/0x800
>  __sync_filesystem+0x83/0x100
>  sync_filesystem+0x89/0xf0
>  generic_shutdown_super+0x79/0x3e0
>  kill_block_super+0xa1/0x110
>  deactivate_locked_super+0xac/0x130
>  deactivate_super+0xb6/0xd0
>  cleanup_mnt+0x289/0x400
>  __cleanup_mnt+0x16/0x20
>  task_work_run+0x11c/0x1c0
>  exit_to_user_mode_prepare+0x203/0x210
>  syscall_exit_to_user_mode+0x5b/0x3a0
>  do_syscall_64+0x59/0x70
>  entry_SYSCALL_64_after_hwframe+0x44/0xa9
>  ==================================================================
> 
> Above issue may happen as follows:
> -------------------------------------
> exit_to_user_mode_prepare
>  task_work_run
>   __cleanup_mnt
>    cleanup_mnt
>     deactivate_super
>      deactivate_locked_super
>       kill_block_super
>        generic_shutdown_super
>         shrink_dcache_for_umount
>          dentry = sb->s_root
>          sb->s_root = NULL              <--- Here set NULL
>         sync_filesystem
>          __sync_filesystem
>           sb->s_op->sync_fs > ext4_sync_fs
>            dquot_writeback_dquots
>             sb->dq_op->write_info > ext4_write_info
>              ext4_journal_start(d_inode(sb->s_root), EXT4_HT_QUOTA, 2)
>               d_inode(sb->s_root)
>                s_root->d_inode          <--- Null pointer dereference
> 
> To solve this problem, we use ext4_journal_start_sb directly
> to avoid s_root being used.

Are we syncing the file system after the superblock shutdown and getting
away with it? This does not look good. Do you have a reproducer?

Thanks!
-Lukas

> 
> Signed-off-by: Baokun Li <libaokun1@huawei.com>
> ---
>  fs/ext4/super.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index 9a66abcca1a8..0ce4565422f6 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -6653,7 +6653,7 @@ static int ext4_write_info(struct super_block *sb, int type)
>  	handle_t *handle;
>  
>  	/* Data block + inode block */
> -	handle = ext4_journal_start(d_inode(sb->s_root), EXT4_HT_QUOTA, 2);
> +	handle = ext4_journal_start_sb(sb, EXT4_HT_QUOTA, 2);
>  	if (IS_ERR(handle))
>  		return PTR_ERR(handle);
>  	ret = dquot_commit_info(sb, type);
> -- 
> 2.31.1
>