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.
