linux-ext4 - Re: [PATCH] ext4: verify orphan file size is not too big

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251006172822.2762117-1-clm@meta.com>
Date: Mon, 6 Oct 2025 10:28:10 -0700
From: Chris Mason <clm@...a.com>
To: Jan Kara <jack@...e.cz>
CC: Chris Mason <clm@...a.com>, Ted Tso <tytso@....edu>,
        <linux-ext4@...r.kernel.org>,
        <syzbot+0b92850d68d9b12934f5@...kaller.appspotmail.com>
Subject: Re: [PATCH] ext4: verify orphan file size is not too big

On Tue,  9 Sep 2025 13:22:07 +0200 Jan Kara <jack@...e.cz> wrote:

> In principle orphan file can be arbitrarily large. However orphan replay
> needs to traverse it all and we also pin all its buffers in memory. Thus
> filesystems with absurdly large orphan files can lead to big amounts of
> memory consumed. Limit orphan file size to a sane value and also use
> kvmalloc() for allocating array of block descriptor structures to avoid
> large order allocations for sane but large orphan files.
> 
> Reported-by: syzbot+0b92850d68d9b12934f5@...kaller.appspotmail.com
> Fixes: 02f310fcf47f ("ext4: Speedup ext4 orphan inode handling")
> Signed-off-by: Jan Kara <jack@...e.cz>
> ---
>  fs/ext4/orphan.c | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/ext4/orphan.c b/fs/ext4/orphan.c
> index 524d4658fa40..7e4f48c15c2e 100644
> --- a/fs/ext4/orphan.c
> +++ b/fs/ext4/orphan.c
> @@ -587,9 +587,20 @@ int ext4_init_orphan_info(struct super_block *sb)
>  		ext4_msg(sb, KERN_ERR, "get orphan inode failed");
>  		return PTR_ERR(inode);
>  	}
> +	/*
> +	 * This is just an artificial limit to prevent corrupted fs from
> +	 * consuming absurd amounts of memory when pinning blocks of orphan
> +	 * file in memory.
> +	 */
> +	if (inode->i_size > 8 << 20) {
> +		ext4_msg(sb, KERN_ERR, "orphan file too big: %llu",
> +			 (unsigned long long)inode->i_size);
> +		ret = -EFSCORRUPTED;
> +		goto out_put;
> +	}
>  	oi->of_blocks = inode->i_size >> sb->s_blocksize_bits;
>  	oi->of_csum_seed = EXT4_I(inode)->i_csum_seed;
> -	oi->of_binfo = kmalloc_array(oi->of_blocks,
> +	oi->of_binfo = kvmalloc_array(oi->of_blocks,
>  				     sizeof(struct ext4_orphan_block),
>  				     GFP_KERNEL);
>  	if (!oi->of_binfo) {

Hi everyone,

I tripped over this while testing some review automation on linux-next.

Should we swap all the kfree(oi->of_binfo) to kvfree?

-chris