[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Y0clWyDlLzG+Eqvx@slm.duckdns.org>
Date: Wed, 12 Oct 2022 10:36:43 -1000
From: Tejun Heo <tj@...nel.org>
To: syzbot <syzbot+141cc7ede4844354c9c5@...kaller.appspotmail.com>
Cc: gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] memory leak in kernfs_fop_open
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@...kaller.appspotmail.com
>
> 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
Powered by blists - more mailing lists