Re: [syzbot] WARNING in iov_iter_revert (3)

[Theodore Ts'o]

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/20221014084837.1787196-1-hrkanabar@xxxxxxxxx/