Re: general protection fault in klist_put

Re: general protection fault in klist_put

[Greg KH]

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?

thanks,

greg k-h

Re: general protection fault in klist_put

[Dmitry Vyukov]

On Sun, Nov 5, 2017 at 11:33 AM, Greg KH <gregkh@linuxfoundation.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