[syzbot] [ext4?] kernel panic: EXT4-fs (device loop0): panic forced after error (2)

[syzbot] [ext4?] kernel panic: EXT4-fs (device loop0): panic forced after error (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    72a85e2b0a1e Merge tag 'spi-fix-v6.2-rc1' of git://git.ker..
git tree:       upstream
console+strace: https://syzkaller.appspot.com/x/log.txt?x=13527f8c480000
kernel config:  https://syzkaller.appspot.com/x/.config?x=4e2d7bfa2d6d5a76
dashboard link: https://syzkaller.appspot.com/bug?extid=3c45794f522ad93b0eb6
compiler:       Debian clang version 13.0.1-++20220126092033+75e33f71c2da-1~exp1~20220126212112.63, GNU ld (GNU Binutils for Debian) 2.35.2
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=12d7f2e4480000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=10c8d2ac480000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/510d16df06c8/disk-72a85e2b.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/50ef5477a1d4/vmlinux-72a85e2b.xz
kernel image: https://storage.googleapis.com/syzbot-assets/f2acd6f1189a/bzImage-72a85e2b.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/6f0bbc430a64/mount_0.gz

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

loop0: detected capacity change from 0 to 512
EXT4-fs error (device loop0): ext4_map_blocks:607: inode #2: block 2: comm syz-executor170: lblock 0 mapped to illegal pblock 2 (length 1)
Kernel panic - not syncing: EXT4-fs (device loop0): panic forced after error
CPU: 1 PID: 5069 Comm: syz-executor170 Not tainted 6.1.0-syzkaller-14594-g72a85e2b0a1e #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x1b1/0x290 lib/dump_stack.c:106
 panic+0x2d6/0x710 kernel/panic.c:318
 ext4_handle_error+0x848/0x8a0 fs/ext4/super.c:685
 __ext4_error_inode+0x2e1/0x4c0 fs/ext4/super.c:808
 ext4_map_blocks+0xadf/0x1cc0
 ext4_getblk+0x1b9/0x770 fs/ext4/inode.c:864
 ext4_bread+0x2a/0x170 fs/ext4/inode.c:920
 __ext4_read_dirblock+0xc9/0x890 fs/ext4/namei.c:144
 dx_probe+0xb7/0x1590 fs/ext4/namei.c:818
 ext4_dx_find_entry fs/ext4/namei.c:1771 [inline]
 __ext4_find_entry+0x599/0x1ba0 fs/ext4/namei.c:1616
 ext4_lookup_entry fs/ext4/namei.c:1752 [inline]
 ext4_lookup+0x11c/0x690 fs/ext4/namei.c:1820
 __lookup_slow+0x266/0x3a0 fs/namei.c:1685
 lookup_slow fs/namei.c:1702 [inline]
 lookup_one_unlocked+0x3f8/0x670 fs/namei.c:2772
 lookup_one_positive_unlocked fs/namei.c:2801 [inline]
 lookup_positive_unlocked+0x27/0xb0 fs/namei.c:2841
 dquot_quota_on_mount+0x56/0xe0 fs/quota/dquot.c:2514
 ext4_quota_on_mount fs/ext4/orphan.c:316 [inline]
 ext4_orphan_cleanup+0x687/0x1340 fs/ext4/orphan.c:444
 __ext4_fill_super fs/ext4/super.c:5516 [inline]
 ext4_fill_super+0x81cd/0x8700 fs/ext4/super.c:5644
 get_tree_bdev+0x400/0x620 fs/super.c:1282
 vfs_get_tree+0x88/0x270 fs/super.c:1489
 do_new_mount+0x289/0xad0 fs/namespace.c:3145
 do_mount fs/namespace.c:3488 [inline]
 __do_sys_mount fs/namespace.c:3697 [inline]
 __se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fd5f592fbca
Code: 83 c4 08 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffcfa196b78 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fd5f592fbca
RDX: 0000000020000440 RSI: 0000000020000480 RDI: 00007ffcfa196b90
RBP: 00007ffcfa196b90 R08: 00007ffcfa196bd0 R09: 0000000000000474
R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000004
R13: 00005555565362c0 R14: 0000000000000000 R15: 00007ffcfa196bd0
 </TASK>
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
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.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches

Re: [syzbot] [ext4?] kernel panic: EXT4-fs (device loop0): panic forced after error (2)

[Theodore Ts'o]

On Wed, Dec 28, 2022 at 12:16:41PM -0800, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    72a85e2b0a1e Merge tag 'spi-fix-v6.2-rc1' of git://git.ker..
> git tree:       upstream
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=13527f8c480000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=4e2d7bfa2d6d5a76
> dashboard link: https://syzkaller.appspot.com/bug?extid=3c45794f522ad93b0eb6
> compiler:       Debian clang version 13.0.1-++20220126092033+75e33f71c2da-1~exp1~20220126212112.63, GNU ld (GNU Binutils for Debian) 2.35.2
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=12d7f2e4480000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=10c8d2ac480000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/510d16df06c8/disk-72a85e2b.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/50ef5477a1d4/vmlinux-72a85e2b.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/f2acd6f1189a/bzImage-72a85e2b.xz
> mounted in repro: https://storage.googleapis.com/syzbot-assets/6f0bbc430a64/mount_0.gz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+3c45794f522ad93b0eb6@syzkaller.appspotmail.com
> 
> loop0: detected capacity change from 0 to 512
> EXT4-fs error (device loop0): ext4_map_blocks:607: inode #2: block 2: comm syz-executor170: lblock 0 mapped to illegal pblock 2 (length 1)
> Kernel panic - not syncing: EXT4-fs (device loop0): panic forced after error

So this is a totally bogus Syzbot report.  If you use the mount option
"errors=panic", and you feed ext4 a corrupted file system, then it
*will* issue an "Ext4-fs error" message, and if you tell it to panic,
it will panic.

So *please* let's not have some crazy Red Hat principal engineer try
to file this as a high severity CVE....

This is Working As Intended.  And it is Not A Bug.

     		   	      	     	- Ted

Re: [syzbot] [ext4?] kernel panic: EXT4-fs (device loop0): panic forced after error (2)

[Aleksandr Nogikh]

Hi Ted,

Syzkaller already tries to avoid such situations, but in this
particular case, it has corrupted the mount options[1] and did not
recognize the problem. Though, as I understand, this string was
nevertheless valid to the kernel. Otherwise it would have aborted the
mount early (?).

I've sent a PR that should make the syzkaller logic more robust to
such broken options strings:
https://github.com/google/syzkaller/pull/3604

[1] grpjquota=Jnoinit_itable(errors=remount-ro,minixdf,jqfmt=vfsv0,usrjquota=."

--
Aleksandr

On Thu, Dec 29, 2022 at 12:14 AM Theodore Ts'o <tytso@mit.edu> wrote:
>
> So this is a totally bogus Syzbot report.  If you use the mount option
> "errors=panic", and you feed ext4 a corrupted file system, then it
> *will* issue an "Ext4-fs error" message, and if you tell it to panic,
> it will panic.
>
> So *please* let's not have some crazy Red Hat principal engineer try
> to file this as a high severity CVE....
>
> This is Working As Intended.  And it is Not A Bug.
>
>                                         - Ted
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/Y6zN/Q3glUcbty%2Bc%40mit.edu.

Re: [syzbot] [ext4?] kernel panic: EXT4-fs (device loop0): panic forced after error (2)

[Theodore Ts'o]

On Tue, Jan 03, 2023 at 12:22:53PM +0100, Aleksandr Nogikh wrote:
> Hi Ted,
> 
> Syzkaller already tries to avoid such situations, but in this
> particular case, it has corrupted the mount options[1] and did not
> recognize the problem. Though, as I understand, this string was
> nevertheless valid to the kernel. Otherwise it would have aborted the
> mount early (?).
> 
> [1] grpjquota=Jnoinit_itable(errors=remount-ro,minixdf,jqfmt=vfsv0,usrjquota=."

Yes, it's considered valid with the name of the journaled group quota
file being "Jnoinit_itable(errors=remount-ro".  Which is very odd, but
in theory, if that file existed, quotaon would have tried to find that
file and used it as the group quota.

(Old-style quota files, which we still support because (a) there might
be RHEL users using system setups that haven't been updated since the
RHEL3/RHEL4 days and (b) there are still stackoverflow answers and
other FAQ posts on the web telling people how to enable quota using
these ancient schemes, are passed into kernel, but aren't actually
used by the kernel; instead the userspace quota tools parse either
/etc/mtab or /proc/mounts to find the relevant mount option and then
try to use the named file as the user or group quota file.)

> I've sent a PR that should make the syzkaller logic more robust to
> such broken options strings:
> https://github.com/google/syzkaller/pull/3604

Thanks for fixing this so promptly!

						- Ted