Messages in this thread | | | Subject | Re: memory leak in pty_common_install | From | Jiri Slaby <> | Date | Sat, 3 Aug 2019 16:22:15 +0200 |
| |
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
| |