ucount: use-after-free read in inc_ucount & dec_ucount

[Eric W. Biederman]

Dmitry Vyukov <dvyukov at google.com> writes:

> On Sun, Mar 5, 2017 at 10:00 PM, Eric W. Biederman
> <ebiederm at xmission.com> wrote:
>> 쪼르 <zzoru007 at gmail.com> 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.

Eric