[syzbot] [ext4?] UBSAN: shift-out-of-bounds in ext2_fill_super (2)

[syzbot] [ext4?] UBSAN: shift-out-of-bounds in ext2_fill_super (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    908f31f2a05b Merge branch 'for-next/core', remote-tracking..
git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
console output: https://syzkaller.appspot.com/x/log.txt?x=124e9053280000
kernel config:  https://syzkaller.appspot.com/x/.config?x=c1058fe68f4b7b2c
dashboard link: https://syzkaller.appspot.com/bug?extid=af5e10f73dbff48f70af
compiler:       Debian clang version 15.0.7, GNU ld (GNU Binutils for Debian) 2.35.2
userspace arch: arm64
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=10f66595280000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14abde43280000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/87d095820229/disk-908f31f2.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/a1bf67af9675/vmlinux-908f31f2.xz
kernel image: https://storage.googleapis.com/syzbot-assets/7784a88b37e8/Image-908f31f2.gz.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/2816e591e0fa/mount_0.gz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+af5e10f73dbff48f70af@syzkaller.appspotmail.com

memfd_create() without MFD_EXEC nor MFD_NOEXEC_SEAL, pid=5969 'syz-executor354'
loop0: detected capacity change from 0 to 512
EXT2-fs (loop0): (no)user_xattr optionsnot supported
================================================================================
UBSAN: shift-out-of-bounds in fs/ext2/super.c:1015:40
shift exponent 63 is too large for 32-bit type 'int'
CPU: 0 PID: 5969 Comm: syz-executor354 Not tainted 6.4.0-rc4-syzkaller-g908f31f2a05b #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023
Call trace:
 dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:233
 show_stack+0x2c/0x44 arch/arm64/kernel/stacktrace.c:240
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106
 dump_stack+0x1c/0x28 lib/dump_stack.c:113
 ubsan_epilogue lib/ubsan.c:217 [inline]
 __ubsan_handle_shift_out_of_bounds+0x2f4/0x36c lib/ubsan.c:387
 ext2_fill_super+0x2270/0x2450 fs/ext2/super.c:1015
 mount_bdev+0x274/0x370 fs/super.c:1380
 ext2_mount+0x44/0x58 fs/ext2/super.c:1491
 legacy_get_tree+0xd4/0x16c fs/fs_context.c:610
 vfs_get_tree+0x90/0x274 fs/super.c:1510
 do_new_mount+0x25c/0x8c4 fs/namespace.c:3039
 path_mount+0x590/0xe04 fs/namespace.c:3369
 do_mount fs/namespace.c:3382 [inline]
 __do_sys_mount fs/namespace.c:3591 [inline]
 __se_sys_mount fs/namespace.c:3568 [inline]
 __arm64_sys_mount+0x45c/0x594 fs/namespace.c:3568
 __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]
 invoke_syscall+0x98/0x2c0 arch/arm64/kernel/syscall.c:52
 el0_svc_common+0x138/0x244 arch/arm64/kernel/syscall.c:142
 do_el0_svc+0x64/0x198 arch/arm64/kernel/syscall.c:191
 el0_svc+0x4c/0x160 arch/arm64/kernel/entry-common.c:647
 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:665
 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591
================================================================================
EXT2-fs (loop0): error: can't find an ext2 filesystem on dev loop0.


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the bug is already fixed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to change bug's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the bug is a duplicate of another bug, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

Re: [syzbot] [ext4?] UBSAN: shift-out-of-bounds in ext2_fill_super (2)

[Theodore Ts'o]

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.

Jan, as the ext2 maintainer, do you have an opinion?

						   - Ted

On Mon, Jun 12, 2023 at 04:58:57PM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    908f31f2a05b Merge branch 'for-next/core', remote-tracking..
> git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
> console output: https://syzkaller.appspot.com/x/log.txt?x=124e9053280000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=c1058fe68f4b7b2c
> dashboard link: https://syzkaller.appspot.com/bug?extid=af5e10f73dbff48f70af
> compiler:       Debian clang version 15.0.7, GNU ld (GNU Binutils for Debian) 2.35.2
> userspace arch: arm64
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=10f66595280000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14abde43280000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/87d095820229/disk-908f31f2.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/a1bf67af9675/vmlinux-908f31f2.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/7784a88b37e8/Image-908f31f2.gz.xz
> mounted in repro: https://storage.googleapis.com/syzbot-assets/2816e591e0fa/mount_0.gz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+af5e10f73dbff48f70af@syzkaller.appspotmail.com
> 
> memfd_create() without MFD_EXEC nor MFD_NOEXEC_SEAL, pid=5969 'syz-executor354'
> loop0: detected capacity change from 0 to 512
> EXT2-fs (loop0): (no)user_xattr optionsnot supported
> ================================================================================
> UBSAN: shift-out-of-bounds in fs/ext2/super.c:1015:40
> shift exponent 63 is too large for 32-bit type 'int'
> CPU: 0 PID: 5969 Comm: syz-executor354 Not tainted 6.4.0-rc4-syzkaller-g908f31f2a05b #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023
> Call trace:
>  dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:233
>  show_stack+0x2c/0x44 arch/arm64/kernel/stacktrace.c:240
>  __dump_stack lib/dump_stack.c:88 [inline]
>  dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106
>  dump_stack+0x1c/0x28 lib/dump_stack.c:113
>  ubsan_epilogue lib/ubsan.c:217 [inline]
>  __ubsan_handle_shift_out_of_bounds+0x2f4/0x36c lib/ubsan.c:387
>  ext2_fill_super+0x2270/0x2450 fs/ext2/super.c:1015
>  mount_bdev+0x274/0x370 fs/super.c:1380
>  ext2_mount+0x44/0x58 fs/ext2/super.c:1491
>  legacy_get_tree+0xd4/0x16c fs/fs_context.c:610
>  vfs_get_tree+0x90/0x274 fs/super.c:1510
>  do_new_mount+0x25c/0x8c4 fs/namespace.c:3039
>  path_mount+0x590/0xe04 fs/namespace.c:3369
>  do_mount fs/namespace.c:3382 [inline]
>  __do_sys_mount fs/namespace.c:3591 [inline]
>  __se_sys_mount fs/namespace.c:3568 [inline]
>  __arm64_sys_mount+0x45c/0x594 fs/namespace.c:3568
>  __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]
>  invoke_syscall+0x98/0x2c0 arch/arm64/kernel/syscall.c:52
>  el0_svc_common+0x138/0x244 arch/arm64/kernel/syscall.c:142
>  do_el0_svc+0x64/0x198 arch/arm64/kernel/syscall.c:191
>  el0_svc+0x4c/0x160 arch/arm64/kernel/entry-common.c:647
>  el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:665
>  el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591
> ================================================================================
> EXT2-fs (loop0): error: can't find an ext2 filesystem on dev loop0.
> 
> 
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
> 
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> 
> If the bug is already fixed, let syzbot know by replying with:
> #syz fix: exact-commit-title
> 
> If you want syzbot to run the reproducer, reply with:
> #syz test: git://repo/address.git branch-or-commit-hash
> If you attach or paste a git patch, syzbot will apply it before testing.
> 
> If you want to change bug's subsystems, reply with:
> #syz set subsystems: new-subsystem
> (See the list of subsystem names on the web dashboard)
> 
> If the bug is a duplicate of another bug, reply with:
> #syz dup: exact-subject-of-another-report
> 
> If you want to undo deduplication, reply with:
> #syz undup

Re: [syzbot] [ext4?] UBSAN: shift-out-of-bounds in ext2_fill_super (2)

[Jan Kara]

On Tue 13-06-23 14:01:03, 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.

Yeah, having ext2 driver as a separate subsystem makes sense to me since it
is completely different codebase.

> 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.
> 
> Jan, as the ext2 maintainer, do you have an opinion?

I agree, I try to fix these problems when syzbot finds them. For this one,
I've already sent a fix [1] (dropping remains of fragments support from ext2).

								Honza

[1] https://lore.kernel.org/all/20230613103012.22933-1-jack@suse.cz

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

Re: [syzbot] [ext4?] UBSAN: shift-out-of-bounds in ext2_fill_super (2)

[Dave Chinner]

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

Re: [syzbot] [ext4?] UBSAN: shift-out-of-bounds in ext2_fill_super (2)

[Jan Kara]

On Fri 16-06-23 09:24:12, Dave Chinner wrote:
> 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.

Yeah, modern is a stretch. But I guess what Ted meant is that we try to
keep ext2 reasonably uptodate with various infrastructure changes. We have
now queued conversion of ext2 direct IO path to iomap and are looking into
converting buffered IO path to iomap as a sample to get experience for ext4
conversion and also conversion of other "simple" filesystems.

> 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?

That's a fair remark and if there is a general sentiment that ext2 codebase
is not really useful, I certainly won't mind having one less fs to
maintain. I'd just note that having ext2 in git history will not provide
very useful insight into how various current infrastructure changes could
be implemented for simple filesystems.

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