On Mon, Mar 6, 2017 at 5:33 PM, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote:
> Dmitry Vyukov <dvyukov@xxxxxxxxxx> writes:
>
>> On Sun, Mar 5, 2017 at 10:00 PM, Eric W. Biederman
>> <ebiederm@xxxxxxxxxxxx> wrote:
>>> 쪼르 <zzoru007@xxxxxxxxx> writes:
>>>
>>>> Hi, This is my new one report about dec_ucount:
>>>> ps.Sorry for my uncomfortable report. This is my first usage of lkml.
>>>> Syzkaller hit 'KASAN: use-after-free Read in dec_ucount' bug on commit
>>>> .
>>>
>>> You are doing well. Thank you very much for the report.
>>>
>>> Thank you for the reproducer. Unfortunately I am not able to reproduce
>>> the bug with what the code you have posted here.
>>>
>>> From the initial mailing the code said:
>>>
>>>> Syzkaller reproducer:
>>>> # {Threaded:false Collide:false Repeat:true Procs:4 Sandbox:setuid
>>>> Repro:false}
>>>> inotify_init()
>>>
>>> The code you posted says:
>>>
>>>> Syzkaller reproducer:
>>>> # {Threaded:false Collide:false Repeat:true Procs:1 Sandbox:setuid Repro:false}
>>>> semget$private(0x0, 0x400001003, 0x181)
>>>
>>> So I expect syzkaller did not create the same code when you ran it
>>> again. Something easy to miss if you haven't run used a tool like that
>>> much.
>>>
>>> If someone knows how to get the code that syzkaller would generate that
>>> matches the original reproducer I would very much appreciate it so that
>>> we can confirm the bug we have spotted in the code is the bug syzkaller
>>> found.
>>>
>>> Until that point I am going to fix the obvious bug in the code and hope
>>> that fixes the problem.
>>
>>
>> Reliably reproducing such bugs is not possible (how would you expect
>> it to look like?). Your best bet is to write a stress test that
>> provokes the bug, add some sleeps into kernel code and run it for a
>> while with KASAN. Should be reproducible within minutes.
>
> I was not asking for a reliable reproducer. I was asking what code was
> run that triggered the error.
>
> I don't have a clue what the randomly generated code that prompted the
> original kernel error is and it doesn't appear anyone else does either.
>
> The only hint I have is:
>>>> Syzkaller reproducer:
>>>> # {Threaded:false Collide:false Repeat:true Procs:4 Sandbox:setuid
>>>> Repro:false}
>>>> inotify_init()
>
> The code that was posted did not call inotify_init and so I believe that
> was a completely different random piece of code, that has nothing to do
> with this issue.
>
> I don't know syzkaller and it looks non-trivial to install on my system
> and play around with. So I am going to leave futzing with syzkaller to
> people who have been able to figure it out.
>
> Until I have a reasonable understanding of what the code was doing that
> triggered the error I can't say with any certainty that the reported bug
> was fixed.
>
> I would love to be able to say that it looks like the bug that caused
> the error report was fixed.
Here is a C analog of the reproducer:
https://gist.githubusercontent.com/dvyukov/80293e434b1273c6a1cdce5c6b979ab6/raw/a1f5ff3cab17b5e3882b56060efb795b6355bdf2/gistfile1.txt
that JongHwan provided here:
https://groups.google.com/d/msg/syzkaller/crHVWf1QDkU/DrA9uVquDwAJ
It basically just calls inotify_init in parallel processes.
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/containers
