linux-kernel - Re: general protection fault in do_move

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:   Fri, 5 Jul 2019 15:02:54 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Eric Biggers <ebiggers@...nel.org>
Cc:     Al Viro <viro@...iv.linux.org.uk>,
        syzbot <syzbot+6004acbaa1893ad013f0@...kaller.appspotmail.com>,
        Arnd Bergmann <arnd@...db.de>, Jens Axboe <axboe@...nel.dk>,
        Borislav Petkov <bp@...en8.de>,
        Catalin Marinas <catalin.marinas@....com>,
        Christian Brauner <christian@...uner.io>,
        David Howells <dhowells@...hat.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Hannes Reinecke <hare@...e.com>,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Andy Lutomirski <luto@...nel.org>,
        Ingo Molnar <mingo@...hat.com>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "the arch/x86 maintainers" <x86@...nel.org>
Subject: Re: general protection fault in do_move_mount (2)

On Mon, Jul 1, 2019 at 5:18 PM Eric Biggers <ebiggers@...nel.org> wrote:
> > > FYI, it also isn't really appropriate for syzbot to bisect all bugs in new
> > > syscalls to wiring them up to x86, and then blame all the x86 maintainers.
> > > Normally such bugs will be in the syscall itself, regardless of architecture.
> >
> > Agree. Do you think it's something worth handling automatically
> > (stands out of the long tail of other inappropriate cases)? If so, how
> > could we detect such cases? It seems that some of these predicates are
> > quite hard to program. Similar things happen with introduction of new
> > bug detection tools and checks, wiring any functionality to new access
> > points and similar things.
> >
>
> Yes, this case could easily be automatically detected (most of the time) by
> listing the filenames changed in the commit, and checking whether they all match
> the pattern syscall.*\.tbl.  Sure, it's not common, but it could be alongside
> other similar straightforward checks like checking for merge commits and
> checking for commits that only modify Documentation/.
>
> I'm not even asking for more correct bisection results at this point, I'm just
> asking for fewer bad bisection results.


Agree, if we implement a common framework for doing this type of
checks and affecting reporting in some fixed set of ways, adding more
rules can make sense even if they don't affect lots of cases. I filed
https://github.com/google/syzkaller/issues/1271 for this.

There are several open questions, though.
1. The syscall.*\.tbl change is formally the right bisection result
and it communicates a bit of potentially useful information. Do we
want to handle them differently from, say, Documentation/* changes
which are significantly a different type "incorrect".
2. You mentioned merges. It seems that they can be just anything:
completely incorrect results; formally correct, but not the change
that introduced the bug; as well as the totally right commit to blame.
Are you sure we should mark all of them as completely incorrect?