Re: memory leak in pty_common_install

[Jiri Slaby <jslaby@suse.cz>]

On 02. 08. 19, 8:23, Jiri Slaby wrote:
> On 30. 07. 19, 17:08, syzbot wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:    6789f873 Merge tag 'pm-5.3-rc2' of
>> git://git.kernel.org/pu..
>> git tree:       upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=1696897c600000
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=339b6a6b3640d115
>> dashboard link:
>> https://syzkaller.appspot.com/bug?extid=bdebcbf44250d75bdd82
>> compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
>> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=153d7544600000
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+bdebcbf44250d75bdd82@syzkaller.appspotmail.com
>>
>> BUG: memory leak
>> unreferenced object 0xffff88810d84d400 (size 512):
>>   comm "syz-executor.5", pid 7522, jiffies 4294954305 (age 14.260s)
>>   hex dump (first 32 bytes):
>>     50 d4 84 0d 81 88 ff ff e0 ff ff ff 0f 00 00 00  P...............
>>     10 d4 84 0d 81 88 ff ff 10 d4 84 0d 81 88 ff ff  ................
>>   backtrace:
>>     [<000000003d61da44>] kmemleak_alloc_recursive
>> include/linux/kmemleak.h:43 [inline]
>>     [<000000003d61da44>] slab_post_alloc_hook mm/slab.h:522 [inline]
>>     [<000000003d61da44>] slab_alloc mm/slab.c:3319 [inline]
>>     [<000000003d61da44>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548
>>     [<00000000a6239e0a>] kmalloc include/linux/slab.h:552 [inline]
>>     [<00000000a6239e0a>] pty_common_install+0x4e/0x2b0
>> drivers/tty/pty.c:391
> 
> So this is tty_port for o_tty.
> 
> ...
> 
>> BUG: memory leakx
>> unreferenced object 0xffff88810e639800 (size 1024):
>>   comm "syz-executor.5", pid 7522, jiffies 4294954305 (age 14.260s)
>>   hex dump (first 32 bytes):
>>     01 54 00 00 01 00 00 00 00 00 00 00 00 00 00 00  .T..............
>>     00 83 fa 19 82 88 ff ff a0 7f 9b 83 ff ff ff ff  ................
>>   backtrace:
>>     [<000000003d61da44>] kmemleak_alloc_recursive
>> include/linux/kmemleak.h:43 [inline]
>>     [<000000003d61da44>] slab_post_alloc_hook mm/slab.h:522 [inline]
>>     [<000000003d61da44>] slab_alloc mm/slab.c:3319 [inline]
>>     [<000000003d61da44>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548
>>     [<000000001cfffc30>] kmalloc include/linux/slab.h:552 [inline]
>>     [<000000001cfffc30>] kzalloc include/linux/slab.h:748 [inline]
>>     [<000000001cfffc30>] alloc_tty_struct+0x3f/0x290
>> drivers/tty/tty_io.c:2981
>>     [<000000001946a70c>] pty_common_install+0xac/0x2b0
>> drivers/tty/pty.c:399
> 
> And this is o_tty proper. So we leak whole o_tty under some
> circumstances... Trying to reproduce.

And I failed.

Looking into the code, I also can't find the scenario. One virtually
possible could be hangup_work being cancelled while release_one_tty was
scheduled on it. But I see this nowhere.

A C reproducer would help.

> BTW the reproducer says:
> ioctl$TCSETS(r0, 0x40045431, ...)
> 
> But 0x40045431 is TIOCSPTLCK, not TCSETS.
> 
> thanks,-- 
js
suse labs