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

Dmitry Vyukov dvyukov at google.com
Mon Mar 6 09:13:45 UTC 2017


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.


More information about the Containers mailing list