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