Re: [syzbot] memory leak in kernfs_fop_open

[Tejun Heo]

On Wed, Oct 12, 2022 at 10:00:55AM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    e8bc52cb8df8 Merge tag 'driver-core-6.1-rc1' of git://git...
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=15adbd1c880000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=d97b00ebbd65d751
> dashboard link: https://syzkaller.appspot.com/bug?extid=141cc7ede4844354c9c5
> compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=127fb348880000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=140790e8880000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/c383c6221def/disk-e8bc52cb.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/212eadb7e8f5/vmlinux-e8bc52cb.xz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+141cc7ede4844354c9c5@xxxxxxxxxxxxxxxxxxxxxxxxx
> 
> BUG: memory leak
> unreferenced object 0xffff88810bfdeb80 (size 96):
>   comm "udevd", pid 2966, jiffies 4294946369 (age 13.650s)
>   hex dump (first 32 bytes):
>     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>     01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>   backtrace:
>     [<ffffffff816f6911>] kmalloc include/linux/slab.h:600 [inline]
>     [<ffffffff816f6911>] kzalloc include/linux/slab.h:733 [inline]
>     [<ffffffff816f6911>] kernfs_get_open_node fs/kernfs/file.c:568 [inline]
>     [<ffffffff816f6911>] kernfs_fop_open+0x4f1/0x5b0 fs/kernfs/file.c:736
>     [<ffffffff815d909f>] do_dentry_open+0x2ff/0x7c0 fs/open.c:882
>     [<ffffffff815ff9b6>] do_open fs/namei.c:3557 [inline]
>     [<ffffffff815ff9b6>] path_openat+0x1756/0x1be0 fs/namei.c:3691
>     [<ffffffff816026e1>] do_filp_open+0xc1/0x1b0 fs/namei.c:3718
>     [<ffffffff815dca0d>] do_sys_openat2+0xed/0x260 fs/open.c:1310
>     [<ffffffff815dd45f>] do_sys_open fs/open.c:1326 [inline]
>     [<ffffffff815dd45f>] __do_sys_openat fs/open.c:1342 [inline]
>     [<ffffffff815dd45f>] __se_sys_openat fs/open.c:1337 [inline]
>     [<ffffffff815dd45f>] __x64_sys_openat+0x7f/0xe0 fs/open.c:1337
>     [<ffffffff845fc895>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>     [<ffffffff845fc895>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
>     [<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd

I tried to reproduce it on my test setup and then qemu running the syz image
but haven't been successful yet. The bug definitely seems plausible but I
haven't been able to spot anything obvious looking at the code yet either.
I'm a bit out of ideas right now. Will keep thinking about it and come back
to it later.

Thanks.

-- 
tejun