linux-kernel - Re: [PATCH] KVM: X86: Fix scan ioapic use-before-initialization

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]

Message-ID: <05a302d5-4761-9045-ba72-a1e10c461d56@redhat.com>
Date:   Tue, 8 Jan 2019 00:11:20 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Dmitry Vyukov <dvyukov@...gle.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Wanpeng Li <kernellwp@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        dledford@...hat.com, KVM list <kvm@...r.kernel.org>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Wei Wu <ww9210@...il.com>, Kostya Serebryany <kcc@...gle.com>,
        Daniel Vetter <daniel@...ll.ch>,
        syzkaller <syzkaller@...glegroups.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Chris Mason <clm@...com>, Jonathan Corbet <corbet@....net>,
        Kees Cook <keescook@...gle.com>,
        Laura Abbott <labbott@...hat.com>,
        Olof Johansson <olofj@...gle.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Theodore Tso <tytso@...gle.com>, Tim.Bird@...y.com
Subject: Re: [PATCH] KVM: X86: Fix scan ioapic use-before-initialization

On 27/12/18 17:59, Linus Torvalds wrote:
> So the issue seems to be that syzbot is simply not useful enough. It's
> output is too rough for people to take it seriously. You see how the
> report by Wei Wu then got traction, because Wei took a syzbot report
> and added some human background and distilled it down to not be
> "here's a big dump of random information".

We do take it seriously.  Usually the reports are relatively easy to
distill and fix, but when new random multi-threaded use-after-free
comes, doing the bisection in syzkaller might not work because they are
not deterministic in how much it takes to reproduce them.  So the only
way to process them is "look at when it started to happen and stare at
150 commits until you find the culprit", which is of course time
consuming even though the syzkaller script usually gives a clue of which
commit to look at.

I agree with Linus that the report is more or less useless except for
trivial bugs, but I'm not sure what can be done to improve it.  I do use
it for trivial bugs, and at the very least, having many different
reports obviously means "use-after-free" or "dangling pointer" or some
other kind of memory corruption.  I try to prioritize those, but theory
and practice are different.

Paolo