On 11/13/20 9:17 AM, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: af5043c8 Merge tag 'acpi-5.10-rc4' of git://git.kernel.org..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=13e8c906500000
> kernel config: https://syzkaller.appspot.com/x/.config?x=a3f13716fa0212fd
> dashboard link: https://syzkaller.appspot.com/bug?extid=86dc6632faaca40133ab
> compiler: gcc (GCC) 10.1.0-syz 20200507
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=102a57dc500000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=129ca3d6500000
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+86dc6632faaca4013...@syzkaller.appspotmail.com
>
> Warning: Permanently added '10.128.0.84' (ECDSA) to the list of known hosts.
> executing program
> executing program
> BUG: memory leak
> unreferenced object 0xffff888111f15a80 (size 32):
> comm "syz-executor841", pid 8507, jiffies 4294942125 (age 14.070s)
> hex dump (first 32 bytes):
> 25 5e 5d 24 5b 2b 25 5d 28 24 7b 3a 0f 6b 5b 29 %^]$[+%](${:.k[)
> 2d 3a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -:..............
> backtrace:
> [<000000005c6f565d>] kmemdup_nul+0x2d/0x70 mm/util.c:151
> [<0000000054985c27>] vfs_parse_fs_string+0x6e/0xd0 fs/fs_context.c:155
> [<0000000077ef66e4>] generic_parse_monolithic+0xe0/0x130
> fs/fs_context.c:201
> [<00000000d4d4a652>] do_new_mount fs/namespace.c:2871 [inline]
> [<00000000d4d4a652>] path_mount+0xbbb/0x1170 fs/namespace.c:3205
> [<00000000f43f0071>] do_mount fs/namespace.c:3218 [inline]
> [<00000000f43f0071>] __do_sys_mount fs/namespace.c:3426 [inline]
> [<00000000f43f0071>] __se_sys_mount fs/namespace.c:3403 [inline]
> [<00000000f43f0071>] __x64_sys_mount+0x18e/0x1d0 fs/namespace.c:3403
> [<00000000dc5fffd5>] do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
> [<000000004e665669>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
>
Hi David,
Is this a false positive, maybe having to do with this comment from
fs/fsopen.c: ?
/*
* Check the state and apply the configuration. Note that this function is
* allowed to 'steal' the value by setting param->xxx to NULL before returning.
*/
static int vfs_fsconfig_locked(struct fs_context *fc, int cmd,
struct fs_parameter *param)
{
Otherwise please look at the patch below.
Thanks.
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> syzbot can test patches for this issue, for details see:
> https://goo.gl/tpsmEJ#testing-patches
---
From: Randy Dunlap <rdun...@infradead.org>
Callers to vfs_parse_fs_param() should be responsible for freeing
param.string.
Fixes: ecdab150fddb ("vfs: syscall: Add fsconfig() for configuring and managing
a context")
Signed-off-by: Randy Dunlap <rdun...@infradead.org>
Reported-by: syzbot+86dc6632faaca4013...@syzkaller.appspotmail.com
Cc: David Howells <dhowe...@redhat.com>
Cc: Al Viro <v...@zeniv.linux.org.uk>
---
This looks promising to me but I haven't fully tested it yet
because my build/test machine just started acting flaky,
like it is having memory or disk errors.
OTOH, it could have ramifications in other places.
fs/fs_context.c | 1 -
fs/fsopen.c | 4 +++-
2 files changed, 3 insertions(+), 2 deletions(-)
--- linux-next-20201204.orig/fs/fs_context.c
+++ linux-next-20201204/fs/fs_context.c
@@ -128,7 +128,6 @@ int vfs_parse_fs_param(struct fs_context
if (fc->source)
return invalf(fc, "VFS: Multiple sources");
fc->source = param->string;
- param->string = NULL;
return 0;
}
--- linux-next-20201204.orig/fs/fsopen.c
+++ linux-next-20201204/fs/fsopen.c
@@ -262,7 +262,9 @@ static int vfs_fsconfig_locked(struct fs
fc->phase != FS_CONTEXT_RECONF_PARAMS)
return -EBUSY;
- return vfs_parse_fs_param(fc, param);
+ ret = vfs_parse_fs_param(fc, param);
+ kfree(param->string);
+ return ret;
}
fc->phase = FS_CONTEXT_FAILED;
return ret;
