Re: [syzbot] WARNING in iov_iter_revert (3)

Al Viro
2022-11-29T04:04:53Z

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.