lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 29 Nov 2022 04:04:35 +0000
From:   Al Viro <viro@...iv.linux.org.uk>
To:     syzbot <syzbot+8c7a4ca1cc31b7ce7070@...kaller.appspotmail.com>
Cc:     akpm@...ux-foundation.org, dan.j.williams@...el.com, hch@....de,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, syzkaller-bugs@...glegroups.com,
        willy@...radead.org
Subject: Re: [syzbot] WARNING in iov_iter_revert (3)

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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ