linux-kernel - Re: general protection fault in klist

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] [day] [month] [year] [list]

Date:   Mon, 6 Nov 2017 13:11:15 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     syzbot 
        <bot+f841f737eaae84758e88c9d3c5aaf4275c1ce556@...kaller.appspotmail.com>,
        LKML <linux-kernel@...r.kernel.org>,
        syzkaller-bugs@...glegroups.com
Subject: Re: general protection fault in klist_put

On Sun, Nov 5, 2017 at 11:33 AM, Greg KH <gregkh@...uxfoundation.org> wrote:
> On Sun, Nov 05, 2017 at 01:05:01AM -0700, syzbot wrote:
>> Hello,
>>
>> syzkaller hit the following crash on
>> 36ef71cae353f88fd6e095e2aaa3e5953af1685d
>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached
>> Raw console output is attached.
>
> <snip>
>
> Thanks for reporting stuff like this, but really, this format of
> reporting bugs is horrible, it does not contain any hints as to what you
> were doing, nor how to reproduce it at all.
>
> What am I supposed to do with this?  How do I know if this bug is ever
> resolved?  When did it show up?  What workload caused it?
>
> A strace really doesn't help much here, do you have a reproducer?

Hi Greg,

The last question is answered in the provided link:
https://github.com/google/syzkaller/blob/master/docs/syzbot.md#no-reproducer-at-all

We try hard to provide reproducers. And we understand that bugs
without reproducers are not actionable sometimes.
This crash happened. That's a fact. We could keep this fact secret,
but I don't think that keeping it secret makes sense either.
For a significant portion of bugs (I would say close to a half or so),
the crash itself provides enough information to root cause it. E.g.
KASAN reports contain allocation, free and use stacks. Lockdep
deadlock/wrong context reports usually have all necessary info.
WARNING/BUGs can point to immediately preceding missing/wrong syscall
arguments checks. For harder cases, even if it's not possible to root
cause a bug, multiple different reports can provide at least some
hints re root cause. These are the reasons why we still report them.

One of the other ones you complained is caused by a simple
single-threaded preceding kmalloc failure, as Eric pointed out:
https://groups.google.com/d/msg/syzkaller-bugs/KSG_mvGUj4c/MtYD_gD6AgAJ
And you also fixed a bunch of recent bugs in USB without reproducers.

If you don't see this as actionable after spending some minimal time
on this, then we don't ask you to do anything supernatural, let's
leave it aside for now.

Thanks