linux-kernel - Re: [syzbot] WARNING in do

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, 13 Dec 2022 01:44:08 +0000
From:   Al Viro <viro@...iv.linux.org.uk>
To:     Marco Elver <elver@...gle.com>
Cc:     Theodore Ts'o <tytso@....edu>, Hillf Danton <hdanton@...a.com>,
        Matthew Wilcox <willy@...radead.org>,
        syzbot <syzbot+919c5a9be8433b8bf201@...kaller.appspotmail.com>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        syzkaller-bugs@...glegroups.com,
        Aleksandr Nogikh <nogikh@...gle.com>
Subject: Re: [syzbot] WARNING in do_mkdirat

On Mon, Dec 12, 2022 at 08:29:10PM +0100, Marco Elver wrote:

> > > Given the call trace above, how do you know the ntfs3 guys should be also
> > > Cced in addition to AV? What if it would take more than three months for
> > > syzbot to learn the skills in your mind?

Depends.  If you really are talking about the *BOT* learning to do
that on its own, it certainly would take more than 3 months; strong AI
is hard.  If, OTOH, it is not an AI research project and intervention of
somebody capable of passing the Turing test does not violate the purity
of experiment...  Surely converting "if it mounts an image as filesystem
of type $T, grep the tree for "MODULE_ALIAS_FS($T)" and treat that
as if a function from the resulting file had been found in stack trace"
into something usable for the bot should not take more than 3 months,
should it?

If expressing that rule really takes "more than three months", I would
suggest that something is very wrong with the bot architecture...

> Teaching a bot the pattern matching skills of a human is non-trivial.
> The current design will likely do the simplest thing: regex match
> reproducers and map a match to some kernel source dir, for which the
> maintainers are Cc'd. If you have better suggestions on how to
> mechanize subsystem selection based on a reproducer, please shout.

Er...  Yes?  Look, it's really that simple -
for i in `sed -ne 's/.*syz_mount_image$\([_[:alnum:]]*\).*/\1/p' <$REPRO`; do
	git grep -l "MODULE_ALIAS_FS(\"$i\")"
done | sort | uniq
gets you the list of files.  No, I'm not suggesting to go for that kind
of shell use, but it's clearly doable with regex and search over the source
for fixed strings.  Unless something's drastically wrong with the way the
bot is written, it should be capable of something as basic as that...

If it can't do that kind of mapping, precalculating it for given tree is
also not hard:
git grep 'MODULE_ALIAS_FS("'|sed -ne 's/\(.*\):.*MODULE_ALIAS_FS("\([_[:alnum:]]*\)".*/syz_mount_image$\2:\1/p'
will yield lines like
syz_mount_image$ext2:fs/ext2/super.c
syz_mount_image$ext2:fs/ext4/super.c
syz_mount_image$ext3:fs/ext4/super.c
syz_mount_image$ext4:fs/ext4/super.c
etc.  Surely turning *that* into whatever form the bot wants can't
be terribly hard? [*]

All of that assumes that pattern-matching in syzkaller reproducer is
expressible; if "we must do everything by call trace alone" is
a real limitation, we are SOL; stack trace simply doesn't have
that information.  Is there such an architectural limitation?

[*] depending upon config, ext2 could be mounted by ext2.ko and ext4.ko;
both have the same maillist for bug reports, so this ambiguity doesn't
matter - either match would do.