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 for Android: free password hash cracker in your pocket

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

Message-ID: <qwkid6zi3wekavyp5ravu32wlyfqgo5osfnlnsjctsp7godboc@ekwo4ooyutum>
Date: Tue, 7 Oct 2025 14:41:41 +0200
From: Jan Kara <jack@...e.cz>
To: Chris Mason <clm@...a.com>
Cc: Jan Kara <jack@...e.cz>, 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 Mon 06-10-25 10:28:10, Chris Mason wrote:
> 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?

Yes, we should. Thanks for spotting this. I'll send a fix.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR