Hello,
syzbot found the following issue on:
HEAD commit: eb7081409f94 Linux 6.1-rc6
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=105ff881880000
kernel config: https://syzkaller.appspot.com/x/.config?x=8cdf448d3b35234
dashboard link: https://syzkaller.appspot.com/bug?extid=8c7a4ca1cc31b7ce7070
compiler: Debian clang version 13.0.1-++20220126092033+75e33f71c2da-1~exp1~20220126212112.63, GNU ld (GNU Binutils for Debian) 2.35.2
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/4a019f55c517/disk-eb708140.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/eb36e890aa8b/vmlinux-eb708140.xz
kernel image: https://storage.googleapis.com/syzbot-assets/feee2c23ec64/bzImage-eb708140.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: [email protected]
------------[ cut here ]------------
WARNING: CPU: 0 PID: 7897 at lib/iov_iter.c:918 iov_iter_revert+0x394/0x850
Modules linked in:
CPU: 0 PID: 7897 Comm: syz-executor.2 Not tainted 6.1.0-rc6-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
RIP: 0010:iov_iter_revert+0x394/0x850 lib/iov_iter.c:918
Code: 80 3c 01 00 48 8b 5c 24 20 74 08 48 89 df e8 e3 c9 a3 fd 4c 89 2b 48 83 c4 68 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 5c b1 4f fd <0f> 0b eb e8 48 8d 6b 18 48 89 e8 48 c1 e8 03 42 80 3c 28 00 74 08
RSP: 0018:ffffc90015fe7ac8 EFLAGS: 00010287
RAX: ffffffff843ae714 RBX: ffffc90015fe7e40 RCX: 0000000000040000
RDX: ffffc9000c1cc000 RSI: 000000000003ef70 RDI: 000000000003ef71
RBP: fffffffffff80e18 R08: ffffffff843ae3bc R09: fffffbfff1d2f2de
R10: fffffbfff1d2f2de R11: 1ffffffff1d2f2dd R12: fffffffffff80e18
R13: ffffc90015fe7e40 R14: ffffc90015fe7e50 R15: 000000007fefef0c
FS: 00007f212fd7e700(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000c00c59ffb8 CR3: 000000007dc32000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
generic_file_read_iter+0x3d4/0x540 mm/filemap.c:2804
do_iter_read+0x6e3/0xc10 fs/read_write.c:796
vfs_readv fs/read_write.c:916 [inline]
do_preadv+0x1f4/0x330 fs/read_write.c:1008
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:0x7f212f08b639
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f212fd7e168 EFLAGS: 00000246 ORIG_RAX: 0000000000000147
RAX: ffffffffffffffda RBX: 00007f212f1ac1f0 RCX: 00007f212f08b639
RDX: 0000000000000001 RSI: 0000000020000100 RDI: 0000000000000003
RBP: 00007f212f0e6ae9 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffdc886837f R14: 00007f212fd7e300 R15: 0000000000022000
</TASK>
---
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 [email protected].
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
On Fri, 25 Nov 2022 05:37:43 -0800 syzbot <[email protected]> wrote:
> Hello,
Thanks. cc's added.
> syzbot found the following issue on:
>
> HEAD commit: eb7081409f94 Linux 6.1-rc6
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=105ff881880000
> kernel config: https://syzkaller.appspot.com/x/.config?x=8cdf448d3b35234
> dashboard link: https://syzkaller.appspot.com/bug?extid=8c7a4ca1cc31b7ce7070
> compiler: Debian clang version 13.0.1-++20220126092033+75e33f71c2da-1~exp1~20220126212112.63, GNU ld (GNU Binutils for Debian) 2.35.2
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/4a019f55c517/disk-eb708140.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/eb36e890aa8b/vmlinux-eb708140.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/feee2c23ec64/bzImage-eb708140.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: [email protected]
>
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 7897 at lib/iov_iter.c:918 iov_iter_revert+0x394/0x850
> Modules linked in:
> CPU: 0 PID: 7897 Comm: syz-executor.2 Not tainted 6.1.0-rc6-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
> RIP: 0010:iov_iter_revert+0x394/0x850 lib/iov_iter.c:918
> Code: 80 3c 01 00 48 8b 5c 24 20 74 08 48 89 df e8 e3 c9 a3 fd 4c 89 2b 48 83 c4 68 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 5c b1 4f fd <0f> 0b eb e8 48 8d 6b 18 48 89 e8 48 c1 e8 03 42 80 3c 28 00 74 08
> RSP: 0018:ffffc90015fe7ac8 EFLAGS: 00010287
> RAX: ffffffff843ae714 RBX: ffffc90015fe7e40 RCX: 0000000000040000
> RDX: ffffc9000c1cc000 RSI: 000000000003ef70 RDI: 000000000003ef71
> RBP: fffffffffff80e18 R08: ffffffff843ae3bc R09: fffffbfff1d2f2de
> R10: fffffbfff1d2f2de R11: 1ffffffff1d2f2dd R12: fffffffffff80e18
> R13: ffffc90015fe7e40 R14: ffffc90015fe7e50 R15: 000000007fefef0c
> FS: 00007f212fd7e700(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 000000c00c59ffb8 CR3: 000000007dc32000 CR4: 00000000003506f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> <TASK>
> generic_file_read_iter+0x3d4/0x540 mm/filemap.c:2804
> do_iter_read+0x6e3/0xc10 fs/read_write.c:796
> vfs_readv fs/read_write.c:916 [inline]
> do_preadv+0x1f4/0x330 fs/read_write.c:1008
> 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:0x7f212f08b639
> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007f212fd7e168 EFLAGS: 00000246 ORIG_RAX: 0000000000000147
> RAX: ffffffffffffffda RBX: 00007f212f1ac1f0 RCX: 00007f212f08b639
> RDX: 0000000000000001 RSI: 0000000020000100 RDI: 0000000000000003
> RBP: 00007f212f0e6ae9 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> R13: 00007ffdc886837f R14: 00007f212fd7e300 R15: 0000000000022000
> </TASK>
>
>
> ---
> 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 [email protected].
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot has found a reproducer for the following issue on:
HEAD commit: b7b275e60bcd Linux 6.1-rc7
git tree: upstream
console+strace: https://syzkaller.appspot.com/x/log.txt?x=1498138d880000
kernel config: https://syzkaller.appspot.com/x/.config?x=2325e409a9a893e1
dashboard link: https://syzkaller.appspot.com/bug?extid=8c7a4ca1cc31b7ce7070
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=17219fbb880000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=172d94d5880000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/525233126d34/disk-b7b275e6.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/e8299bf41400/vmlinux-b7b275e6.xz
kernel image: https://storage.googleapis.com/syzbot-assets/eebf691dbf6f/bzImage-b7b275e6.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/b1f44a556b42/mount_0.gz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: [email protected]
------------[ cut here ]------------
WARNING: CPU: 0 PID: 3655 at lib/iov_iter.c:918 iov_iter_revert+0x394/0x850
Modules linked in:
CPU: 0 PID: 3655 Comm: syz-executor207 Not tainted 6.1.0-rc7-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
RIP: 0010:iov_iter_revert+0x394/0x850 lib/iov_iter.c:918
Code: 80 3c 01 00 48 8b 5c 24 20 74 08 48 89 df e8 33 c0 a7 fd 4c 89 2b 48 83 c4 68 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 dc a5 53 fd <0f> 0b eb e8 48 8d 6b 18 48 89 e8 48 c1 e8 03 42 80 3c 28 00 74 08
RSP: 0018:ffffc90003c0fac8 EFLAGS: 00010293
RAX: ffffffff8436f214 RBX: ffffc90003c0fe40 RCX: ffff888026a39d40
RDX: 0000000000000000 RSI: fffffffffffa6000 RDI: 000000007ffff000
RBP: fffffffffffa6000 R08: ffffffff8436eebc R09: fffffbfff1cebe0e
R10: fffffbfff1cebe0e R11: 1ffffffff1cebe0d R12: fffffffffffa6000
R13: ffffc90003c0fe40 R14: ffffc90003c0fe50 R15: 000000007ffa4000
FS: 00007fc698110700(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000100 CR3: 00000000235e6000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
generic_file_read_iter+0x3d4/0x540 mm/filemap.c:2804
do_iter_read+0x6e3/0xc10 fs/read_write.c:796
vfs_readv fs/read_write.c:916 [inline]
do_preadv+0x1f4/0x330 fs/read_write.c:1008
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:0x7fc698185789
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 71 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fc6981102e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000147
RAX: ffffffffffffffda RBX: 00007fc6982297b8 RCX: 00007fc698185789
RDX: 0000000000000001 RSI: 0000000020000100 RDI: 0000000000000004
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fc6982297b0
R13: 00007fc6981f67e4 R14: 6573726168636f69 R15: 0030656c69662f2e
</TASK>
On Mon, Nov 28, 2022 at 02:57:49PM -0800, syzbot wrote:
> syzbot has found a reproducer for the following issue on:
[snip]
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17219fbb880000
"syz_mount_image$ntfs3(" followed by arseloads of garbage. And the thing
conspiciously missing? Why, any ntfs3 maintainers in Cc... Or lists,
for that matter...
> generic_file_read_iter+0x3d4/0x540 mm/filemap.c:2804
> do_iter_read+0x6e3/0xc10 fs/read_write.c:796
> vfs_readv fs/read_write.c:916 [inline]
> do_preadv+0x1f4/0x330 fs/read_write.c:1008
> 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
At a guess - something's screwed in ntfs3 ->direct_IO() (return value, most
likely). And something's screwed in syzbot. If you are fuzzing some
filesystem, YOU REALLY OUGHT TO CC THE MAINTAINERS OF THAT FILESYSTEM.
Even if nothing in the stack trace happens to be in that fs.
Folks, it's that simple - "our bot needs to remember that fuzzing $FS
automatically puts maintainers of $FS into the set of people we need to Cc"
vs. "maintainers of each filesystem need to dig into every syzbot posting
on fsdevel (and follow links, no less) to check if their fs might be
involved". If you can't be bothered to take care of the former, why
would you expect $BIGNUM people to bother with the latter, again and
again and again?
Fix your bot, already. It's not the first time this had been brought
to your attention and the problem is still there.
Hello,
syzbot has tested the proposed patch but the reproducer is still triggering an issue:
INFO: rcu detected stall in corrupted
rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { P4109 } 2690 jiffies s: 2793 root: 0x0/T
rcu: blocking rcu_node structures (internal RCU debug):
Tested on:
commit: b7b275e6 Linux 6.1-rc7
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
console output: https://syzkaller.appspot.com/x/log.txt?x=15ab6753880000
kernel config: https://syzkaller.appspot.com/x/.config?x=2325e409a9a893e1
dashboard link: https://syzkaller.appspot.com/bug?extid=8c7a4ca1cc31b7ce7070
compiler: Debian clang version 13.0.1-++20220126092033+75e33f71c2da-1~exp1~20220126212112.63, GNU ld (GNU Binutils for Debian) 2.35.2
patch: https://syzkaller.appspot.com/x/patch.diff?x=100b6753880000
On Tue, Nov 29, 2022 at 05:08:31PM +0800, Hillf Danton wrote:
> On 29 Nov 2022 04:04:35 +0000 Al Viro <[email protected]>
> > On Mon, Nov 28, 2022 at 02:57:49PM -0800, syzbot wrote:
> > > syzbot has found a reproducer for the following issue on:
> >
> > [snip]
> >
> > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17219fbb880000
> >
> > "syz_mount_image$ntfs3(" followed by arseloads of garbage. And the thing
> > conspiciously missing? Why, any ntfs3 maintainers in Cc... Or lists,
> > for that matter...
> >
> > > generic_file_read_iter+0x3d4/0x540 mm/filemap.c:2804
> > > do_iter_read+0x6e3/0xc10 fs/read_write.c:796
> > > vfs_readv fs/read_write.c:916 [inline]
> > > do_preadv+0x1f4/0x330 fs/read_write.c:1008
> > > 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
> >
> > At a guess - something's screwed in ntfs3 ->direct_IO() (return value, most
> > likely).
>
> 2798 retval = mapping->a_ops->direct_IO(iocb, iter);
> 2799 if (retval >= 0) {
> 2800 iocb->ki_pos += retval;
> 2801 count -= retval;
> 2802 }
> 2803 if (retval != -EIOCBQUEUED)
> 2804 iov_iter_revert(iter, count - iov_iter_count(iter));
> 2805
> 2806 /*
> 2807 * Btrfs can have a short DIO read if we encounter
> 2808 * compressed extents, so if there was an error, or if
> 2809 * we've already read everything we wanted to, or if
> 2810 * there was a short read because we hit EOF, go ahead
> 2811 * and return. Otherwise fallthrough to buffered io for
> 2812 * the rest of the read. Buffered reads will not work for
> 2813 * DAX files, so don't bother trying.
> 2814 */
> 2815 if (retval < 0 || !count || IS_DAX(inode))
> 2816 return retval;
> 2817 if (iocb->ki_pos >= i_size_read(inode))
> 2818 return retval;
>
>
> If ntfs3 is supposed to do nothing wrong with retval set to 5, why is
> iov_iter_revert() invoked? Is it correct to check -EIOCBQUEUED only if
> the direct_IO callback returns error?
->direct_IO() should return the amount of data actually copied to userland;
if that's how much it has consumed from iterator - great, iov_iter_revert(i, 0)
is a no-op. If it has consumed more, the caller will take care of that.
If it has consumed say 4Kb of data from iterator, but claims that it has
managed to store 12Kb into that, it's broken and should be fixed.
If it wants to do revert on its own, for whatever reason, it is welcome - nothing
will break, as long as you do *not* return the value greater than the amount you
ended up taking from iterator. However, I don't understand the reason why ntfs3
wants to bother (and appears to get it wrong, at that); the current rules are
such that caller will take care of revert.
On Tue, Nov 29, 2022 at 12:20:39PM +0000, Al Viro wrote:
> ->direct_IO() should return the amount of data actually copied to userland;
> if that's how much it has consumed from iterator - great, iov_iter_revert(i, 0)
> is a no-op. If it has consumed more, the caller will take care of that.
> If it has consumed say 4Kb of data from iterator, but claims that it has
> managed to store 12Kb into that, it's broken and should be fixed.
>
> If it wants to do revert on its own, for whatever reason, it is welcome - nothing
> will break, as long as you do *not* return the value greater than the amount you
> ended up taking from iterator. However, I don't understand the reason why ntfs3
> wants to bother (and appears to get it wrong, at that); the current rules are
> such that caller will take care of revert.
Looking at ntfs3, WTF does it bother with zeroing on short reads (?) in the
first place? Anyway, immediate bug there is the assumption that
blockdev_direct_IO() won't consume more than its return value; it bloody
well might.
*IF* you want that logics on reads (again, I'm not at all sure what is it
doing there), you want this:
} else if (vbo < valid && valid < end) {
size_t consumed = iter_count - iov_iter_count(iter);
size_t valid_bytes = valid - vbo;
iov_iter_revert(iter, consumed - valid_bytes);
iov_iter_zero(ret - valid_bytes, iter);
}
This iov_iter_zero() would better not be an attempt to overwrite some
data that shouldn't have been copied to userland; if that's what it
is, it's an infoleak - another thread might have observed the data
copied there before that zeroing.
Oh, and
if (end > valid && !S_ISBLK(inode->i_mode)) {
several lines above is obvious bollocks - if inode is a block device,
we won't be going anywhere near any NTFS address_space_operations or
ntfs_direct_IO().
Seriously, what's going on with zeroing there?
On Tue, Nov 29, 2022 at 04:04:35AM +0000, Al Viro wrote:
> On Mon, Nov 28, 2022 at 02:57:49PM -0800, syzbot wrote:
> > syzbot has found a reproducer for the following issue on:
>
> [snip]
>
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17219fbb880000
>
> "syz_mount_image$ntfs3(" followed by arseloads of garbage. And the thing
> conspiciously missing? Why, any ntfs3 maintainers in Cc... Or lists,
> for that matter...
>
> > generic_file_read_iter+0x3d4/0x540 mm/filemap.c:2804
> > do_iter_read+0x6e3/0xc10 fs/read_write.c:796
> > vfs_readv fs/read_write.c:916 [inline]
> > do_preadv+0x1f4/0x330 fs/read_write.c:1008
> > 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
>
> At a guess - something's screwed in ntfs3 ->direct_IO() (return value, most
> likely). And something's screwed in syzbot. If you are fuzzing some
> filesystem, YOU REALLY OUGHT TO CC THE MAINTAINERS OF THAT FILESYSTEM.
> Even if nothing in the stack trace happens to be in that fs.
The scheme which syzbot appears to use involves looking at the symbol
in EIP from the stack trace to determine who to CC. This... mostly
works, but occasionally results in hilarity.
For example, there was the time when the fuzzing program fed some
other file system (f2fs, as I recall) several hundred invalid file
systems, and then for some reason it fed ext4 an invalid file system,
and ext4 tripped on an invalid pointer dereference. Of course, just
feeding ext4 the invalid file system had no issues, and a human being
might have intuited that maybe the several hundred invalid f2fs file
systems triggered some kind of memory corruption which ext4 then
tripped across ---- but since the EIP was in the ext4 file system, the
ext4 maintainers got cc'ed, and if you look in the dashboard, it just
shows an ext4 symbol, so it's unlikely the f2fs developers would ever
have discovered it on their own. (I did cc it to them, but they
weren't able to get to it immediately, and it'll be hard to find it
again, since we don't have a bug tracking system and there's no way to
set some kind of "subsystem really at fault" state in the Syzkaller
dashboard.)
> Folks, it's that simple - "our bot needs to remember that fuzzing $FS
> automatically puts maintainers of $FS into the set of people we need to Cc"
> vs. "maintainers of each filesystem need to dig into every syzbot posting
> on fsdevel (and follow links, no less) to check if their fs might be
> involved". If you can't be bothered to take care of the former, why
> would you expect $BIGNUM people to bother with the latter, again and
> again and again?
The strength and weakness of syzkaller is that it will combine fuzzing
with, say, setting up and tearing down a gazllion wireguard tunnels,
or some other random set of system calls. Sometimes that finds a real
bug. Other times, for some strange reason, the syzkaller minimizer
can't figure out that the extraneous noise in setting up and tearing
down the network connections is pointless noise, except that on the
specific hardware/VM used by syzkaller, it helps make it easier to
trigger a timing-related bug --- but $DEITY help you if you try to
reproduce on anything other than the specific VM used by the syzkaller
bug.
And then, of course, there are cases where the reproducer is only
doing one thing, such as say messing with ntfs3, and the syzbot
*should* be able to figure out a better set of maintainers to notify
--- but then, given that the syzbot subjust line/summary is something
generic, such as iov_iter_XXX, and there's no way to set up an
affected subsystem state in the dashboard, good luck having anyone
else find it in the syzkaller dashboard later on.
> Fix your bot, already. It's not the first time this had been brought
> to your attention and the problem is still there.
I've brought this to the Syzkaller team's attention multiple times.
Unfortunately, it's not exactly a trivial problem to solve, and other
things have been considered higher priority.
(Hint to the Syzkaller team; if you can prioritize and share a roadmap
with upstream developer vis-a-vis upstream concerns, it might make
some upstream developers a bit more receptive to patches designed to
make life easier for syzkaller to find EVEN MORE FILESYSTEM FUZZING
BUGS, such as [1]. Otherwise, it is perhaps understandable why some
might consider this more of a threat rather than a benefit... Note:
[1] doesn't make a difference for ext4 either way, since metadata
checksums is a file system feature that can be enabled or disabled at
mkfs time; this patch series is about finding more file system bugs
for file systems which don't make disabling checksum to be an option,
such as XFS.)
[1] https://lore.kernel.org/all/[email protected]/