From: Dave Chinner <david@fromorbit.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Aleksandr Nogikh <nogikh@google.com>,
adilger.kernel@dilger.ca, jack@suse.com,
linux-ext4@vger.kernel.org, syzkaller-bugs@googlegroups.com,
syzbot <syzbot+af5e10f73dbff48f70af@syzkaller.appspotmail.com>
Subject: Re: [syzbot] [ext4?] UBSAN: shift-out-of-bounds in ext2_fill_super (2)
Date: Fri, 16 Jun 2023 09:24:12 +1000 [thread overview]
Message-ID: <ZIudnDI5JZU+4w42@dread.disaster.area> (raw)
In-Reply-To: <20230613180103.GC18303@mit.edu>
On Tue, Jun 13, 2023 at 02:01:03PM -0400, Theodore Ts'o wrote:
> I wonder if we should have a separate syzkaller subsystem for ext2 (as
> distinct from ext4)? The syz reproducer seems to know that it should
> be mounting using ext2, but also calls it an ext4 file system, which
> is a bit weird. I'm guessing there is something specific about the
> syzkaller internals which might not make this be practical, but I
> thought I should ask.
>
> From the syz reproducer:
>
> syz_mount_image$ext4(&(0x7f0000000100)='ext2\x00', ...)
>
> More generally, there are a series of changes that were made to make
> ext4 to make it more robust against maliciously fuzzed superblocks,
> but we haven't necessarily made sure the same analogous changes have
> been made to ext2. I'm not sure how critical this is in practice,
> since most distributions don't actually compile fs/ext2 and instead
> use CONFIG_EXT4_USE_FOR_EXT2 instead. However, while we maintain ext2
> as a sample "simple" modern file system, I guess we should try to make
> sure we do carry those fixes over.
Hmmmm.
Modern filesystems are crash resilient, based on extents and are
using/moving to folios+iomap - calling a non-journalled, indirect
block indexed, bufferhead based code base (that nobody is really
using in production) "modern" seems like a real stretch.
I have my doubts that maintaining fs/ext2 is providing much benefit
to anyone. The code base is in the git history if anyone wants to
study it, so it's not like we have to keep it active in the tree for
it to remain a code base that people can learn from.
Therefore, given the current push to sideline/remove bufferheads
from the kernel, should we simply deprecate fs/ext2 and then remove
it in a year or two like we're doing with reiser to reduce our
future maintenance and/or conversion burden?
Or just remove it right now and simply make CONFIG_FS_EXT2 select
CONFIG_EXT4_USE_FOR_EXT2?
/Devil's Advocate
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2023-06-15 23:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-12 23:58 [syzbot] [ext4?] UBSAN: shift-out-of-bounds in ext2_fill_super (2) syzbot
2023-06-13 18:01 ` Theodore Ts'o
2023-06-13 21:05 ` Jan Kara
2023-06-15 23:24 ` Dave Chinner [this message]
2023-06-16 15:49 ` Jan Kara
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=ZIudnDI5JZU+4w42@dread.disaster.area \
--to=david@fromorbit.com \
--cc=adilger.kernel@dilger.ca \
--cc=jack@suse.com \
--cc=linux-ext4@vger.kernel.org \
--cc=nogikh@google.com \
--cc=syzbot+af5e10f73dbff48f70af@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=tytso@mit.edu \
/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