From: "Theodore Tso" <tytso@mit.edu>
To: Helen Koike <koike@igalia.com>
Cc: adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-dev@igalia.com,
syzbot+b73703b873a33d8eb8f6@syzkaller.appspotmail.com
Subject: Re: [PATCH] ext4: fix bigalloc cluster arithmetic when s_first_data_block != 0
Date: Fri, 13 Mar 2026 21:29:30 -0400 [thread overview]
Message-ID: <20260314012930.GB38016@macsyma-wired.lan> (raw)
In-Reply-To: <20260313151835.1248953-1-koike@igalia.com>
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.
> 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;
}
> 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.
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.
Cheers,
- Ted
next prev parent reply other threads:[~2026-03-14 1:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-13 15:18 [PATCH] ext4: fix bigalloc cluster arithmetic when s_first_data_block != 0 Helen Koike
2026-03-13 15:28 ` Helen Koike
2026-03-14 1:29 ` Theodore Tso [this message]
2026-03-17 13:53 ` Helen Koike
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260314012930.GB38016@macsyma-wired.lan \
--to=tytso@mit.edu \
--cc=adilger.kernel@dilger.ca \
--cc=kernel-dev@igalia.com \
--cc=koike@igalia.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=syzbot+b73703b873a33d8eb8f6@syzkaller.appspotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox