Re: [PATCH] ext4: fix bigalloc cluster arithmetic when s_first_data_block != 0

[Helen Koike <koike@igalia.com>]

Hi Ted,


On 3/13/26 10:29 PM, Theodore Tso wrote:
> On Fri, Mar 13, 2026 at 12:18:30PM -0300, Helen Koike wrote:
>> On filesystems with bigalloc enabled and s_first_data_block != 0,
> 
> This is never supposed to happen; fsck already checks for this.  From
> e2fsck/super.c:
> 
> 	should_be = (sb->s_log_block_size == 0 &&
> 		     EXT2FS_CLUSTER_RATIO(fs) == 1) ? 1 : 0;
> 	if (sb->s_first_data_block != should_be) {
> 		pctx.blk = sb->s_first_data_block;
> 		pctx.blk2 = should_be;
> 		fix_problem(ctx, PR_0_FIRST_DATA_BLOCK, &pctx);
> 		ctx->flags |= E2F_FLAG_ABORT;
> 		return;
> 	}
> 
> You can also see evidence of this code path getting trigger by
> clicking on "corrupt_fs" in the Syzkaller dashboard.

I see, thanks for the pointers.

> 
>> Introduce four macros that subtract s_first_data_block before
>> operating, matching the coordinate system used by mballoc:
> 
> This is *way* more complicated than it needs to be.  All you need to
> do is just reject the mount if the file system is this insanely
> corrupted.  For example:
> 
> 	if (ext4_has_feature_bigalloc(sb) &&
> 	    es->s_first_data_block) {
> 		ext4_msg(sb, KERN_WARNING, "bad geometry: bigalloc "
> 			 "file system with non-zero first_data_block");
> 		return -EINVAL;
> 	}

Agreed. I thought it should be supported from [1] but I missed [2].

[1] https://lore.kernel.org/all/20130221134943.GA3818@gmail.com/
[2] https://lore.kernel.org/all/20130222030327.GB3421@gmail.com/

> 
>> Regarding the issue reported by syzbot...
> 
> Yeah, this is why I generally don't pay that much attention to syzbot
> reports that mount a corrupted file system.  Users are supposed to run
> fsck on a file system before they blindly mount it.  If they don't, I
> don't consider it a security vulnerability; it's just a stupid system
> administrator trick, and he or she deserves everything that happens to
> them.  Hence, such issues are not a security issue, but just a quality
> of implementation issue.  I'll accept patches to addrese sorts of
> things, but it doesn't rate a CVE or high priority processing.

Make sense.

I think I'll submit this patch as per your suggestion since I'm already 
looking at this, but I won't bother you further with these sorts of 
low-priority issues.

> 
> Furthermore, any fix needs to as simple as possible, and avoids adding
> extra overhead especially on hot paths.  In this particular case,
> rejecting the mount is the simplest fix, since the file system
> corruption is *easy* to detect.

Ack, and thanks for your reply!

Helen,
Cheers