* memory leak in gfs2_init_fs_context
@ 2019-10-03 0:19 ` syzbot
0 siblings, 0 replies; 8+ messages in thread
From: syzbot @ 2019-10-03 0:19 UTC (permalink / raw)
To: agruenba, cluster-devel, linux-kernel, rpeterso, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: f1f2f614 Merge branch 'next-integrity' of git://git.kernel..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15569c05600000
kernel config: https://syzkaller.appspot.com/x/.config?x=4e93436f92b0cfde
dashboard link: https://syzkaller.appspot.com/bug?extid=c2fdfd2b783754878fb6
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10327c05600000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=105c9fd5600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+c2fdfd2b783754878fb6@syzkaller.appspotmail.com
udit: type=1400 audit(1569701659.045:64): avc: denied { map } for
pid=6842 comm="syz-executor375" path="/root/syz-executor375626622"
dev="sda1" ino=16502 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
executing program
executing program
BUG: memory leak
unreferenced object 0xffff88810fd9a500 (size 256):
comm "syz-executor375", pid 6845, jiffies 4294941255 (age 13.550s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000462ab467>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<00000000462ab467>] slab_post_alloc_hook mm/slab.h:586 [inline]
[<00000000462ab467>] slab_alloc mm/slab.c:3319 [inline]
[<00000000462ab467>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548
[<00000000b1a62211>] kmalloc include/linux/slab.h:552 [inline]
[<00000000b1a62211>] kzalloc include/linux/slab.h:686 [inline]
[<00000000b1a62211>] gfs2_init_fs_context+0x25/0x90
fs/gfs2/ops_fstype.c:1543
[<00000000db94ecb4>] gfs2_meta_init_fs_context+0x17/0x40
fs/gfs2/ops_fstype.c:1608
[<0000000077df5577>] alloc_fs_context+0x174/0x200 fs/fs_context.c:293
[<000000008d5e3681>] fs_context_for_mount+0x25/0x30 fs/fs_context.c:307
[<0000000030bafbdb>] __do_sys_fsopen fs/fsopen.c:137 [inline]
[<0000000030bafbdb>] __se_sys_fsopen fs/fsopen.c:115 [inline]
[<0000000030bafbdb>] __x64_sys_fsopen+0xa9/0x1a0 fs/fsopen.c:115
[<00000000974fed69>] do_syscall_64+0x73/0x1f0
arch/x86/entry/common.c:290
[<00000000299e0e1b>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff88810fd9a200 (size 256):
comm "syz-executor375", pid 6846, jiffies 4294941838 (age 7.720s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000462ab467>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<00000000462ab467>] slab_post_alloc_hook mm/slab.h:586 [inline]
[<00000000462ab467>] slab_alloc mm/slab.c:3319 [inline]
[<00000000462ab467>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548
[<00000000b1a62211>] kmalloc include/linux/slab.h:552 [inline]
[<00000000b1a62211>] kzalloc include/linux/slab.h:686 [inline]
[<00000000b1a62211>] gfs2_init_fs_context+0x25/0x90
fs/gfs2/ops_fstype.c:1543
[<00000000db94ecb4>] gfs2_meta_init_fs_context+0x17/0x40
fs/gfs2/ops_fstype.c:1608
[<0000000077df5577>] alloc_fs_context+0x174/0x200 fs/fs_context.c:293
[<000000008d5e3681>] fs_context_for_mount+0x25/0x30 fs/fs_context.c:307
[<0000000030bafbdb>] __do_sys_fsopen fs/fsopen.c:137 [inline]
[<0000000030bafbdb>] __se_sys_fsopen fs/fsopen.c:115 [inline]
[<0000000030bafbdb>] __x64_sys_fsopen+0xa9/0x1a0 fs/fsopen.c:115
[<00000000974fed69>] do_syscall_64+0x73/0x1f0
arch/x86/entry/common.c:290
[<00000000299e0e1b>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
---
This bug 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 syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Cluster-devel] memory leak in gfs2_init_fs_context
@ 2019-10-03 0:19 ` syzbot
0 siblings, 0 replies; 8+ messages in thread
From: syzbot @ 2019-10-03 0:19 UTC (permalink / raw)
To: cluster-devel.redhat.com
Hello,
syzbot found the following crash on:
HEAD commit: f1f2f614 Merge branch 'next-integrity' of git://git.kernel..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15569c05600000
kernel config: https://syzkaller.appspot.com/x/.config?x=4e93436f92b0cfde
dashboard link: https://syzkaller.appspot.com/bug?extid=c2fdfd2b783754878fb6
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10327c05600000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=105c9fd5600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+c2fdfd2b783754878fb6 at syzkaller.appspotmail.com
udit: type=1400 audit(1569701659.045:64): avc: denied { map } for
pid=6842 comm="syz-executor375" path="/root/syz-executor375626622"
dev="sda1" ino=16502 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
executing program
executing program
BUG: memory leak
unreferenced object 0xffff88810fd9a500 (size 256):
comm "syz-executor375", pid 6845, jiffies 4294941255 (age 13.550s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000462ab467>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<00000000462ab467>] slab_post_alloc_hook mm/slab.h:586 [inline]
[<00000000462ab467>] slab_alloc mm/slab.c:3319 [inline]
[<00000000462ab467>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548
[<00000000b1a62211>] kmalloc include/linux/slab.h:552 [inline]
[<00000000b1a62211>] kzalloc include/linux/slab.h:686 [inline]
[<00000000b1a62211>] gfs2_init_fs_context+0x25/0x90
fs/gfs2/ops_fstype.c:1543
[<00000000db94ecb4>] gfs2_meta_init_fs_context+0x17/0x40
fs/gfs2/ops_fstype.c:1608
[<0000000077df5577>] alloc_fs_context+0x174/0x200 fs/fs_context.c:293
[<000000008d5e3681>] fs_context_for_mount+0x25/0x30 fs/fs_context.c:307
[<0000000030bafbdb>] __do_sys_fsopen fs/fsopen.c:137 [inline]
[<0000000030bafbdb>] __se_sys_fsopen fs/fsopen.c:115 [inline]
[<0000000030bafbdb>] __x64_sys_fsopen+0xa9/0x1a0 fs/fsopen.c:115
[<00000000974fed69>] do_syscall_64+0x73/0x1f0
arch/x86/entry/common.c:290
[<00000000299e0e1b>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff88810fd9a200 (size 256):
comm "syz-executor375", pid 6846, jiffies 4294941838 (age 7.720s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000462ab467>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<00000000462ab467>] slab_post_alloc_hook mm/slab.h:586 [inline]
[<00000000462ab467>] slab_alloc mm/slab.c:3319 [inline]
[<00000000462ab467>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548
[<00000000b1a62211>] kmalloc include/linux/slab.h:552 [inline]
[<00000000b1a62211>] kzalloc include/linux/slab.h:686 [inline]
[<00000000b1a62211>] gfs2_init_fs_context+0x25/0x90
fs/gfs2/ops_fstype.c:1543
[<00000000db94ecb4>] gfs2_meta_init_fs_context+0x17/0x40
fs/gfs2/ops_fstype.c:1608
[<0000000077df5577>] alloc_fs_context+0x174/0x200 fs/fs_context.c:293
[<000000008d5e3681>] fs_context_for_mount+0x25/0x30 fs/fs_context.c:307
[<0000000030bafbdb>] __do_sys_fsopen fs/fsopen.c:137 [inline]
[<0000000030bafbdb>] __se_sys_fsopen fs/fsopen.c:115 [inline]
[<0000000030bafbdb>] __x64_sys_fsopen+0xa9/0x1a0 fs/fsopen.c:115
[<00000000974fed69>] do_syscall_64+0x73/0x1f0
arch/x86/entry/common.c:290
[<00000000299e0e1b>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
---
This bug 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 syzkaller at googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH] gfs2: Fix memory leak when gfs2meta's fs_context is freed
2019-10-03 0:19 ` [Cluster-devel] " syzbot
@ 2019-10-03 15:35 ` Andrew Price
-1 siblings, 0 replies; 8+ messages in thread
From: Andrew Price @ 2019-10-03 15:35 UTC (permalink / raw)
To: cluster-devel; +Cc: linux-kernel, syzkaller-bugs, syzbot+c2fdfd2b783754878fb6
gfs2 and gfs2meta share an ->init_fs_context function which allocates an
args structure stored in fc->fs_private. gfs2 registers a ->free
function to free this memory when the fs_context is cleaned up, but
there was not one registered for gfs2meta, causing a leak.
Register a ->free function for gfs2meta. The existing gfs2_fc_free
function does what we need.
Reported-by: syzbot+c2fdfd2b783754878fb6@syzkaller.appspotmail.com
Signed-off-by: Andrew Price <anprice@redhat.com>
---
fs/gfs2/ops_fstype.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/gfs2/ops_fstype.c b/fs/gfs2/ops_fstype.c
index 681b44682b0d..dc61af2c4d5e 100644
--- a/fs/gfs2/ops_fstype.c
+++ b/fs/gfs2/ops_fstype.c
@@ -1600,6 +1600,7 @@ static int gfs2_meta_get_tree(struct fs_context *fc)
}
static const struct fs_context_operations gfs2_meta_context_ops = {
+ .free = gfs2_fc_free,
.get_tree = gfs2_meta_get_tree,
};
--
2.21.0
^ permalink raw reply related [flat|nested] 8+ messages in thread
* [Cluster-devel] [PATCH] gfs2: Fix memory leak when gfs2meta's fs_context is freed
@ 2019-10-03 15:35 ` Andrew Price
0 siblings, 0 replies; 8+ messages in thread
From: Andrew Price @ 2019-10-03 15:35 UTC (permalink / raw)
To: cluster-devel.redhat.com
gfs2 and gfs2meta share an ->init_fs_context function which allocates an
args structure stored in fc->fs_private. gfs2 registers a ->free
function to free this memory when the fs_context is cleaned up, but
there was not one registered for gfs2meta, causing a leak.
Register a ->free function for gfs2meta. The existing gfs2_fc_free
function does what we need.
Reported-by: syzbot+c2fdfd2b783754878fb6 at syzkaller.appspotmail.com
Signed-off-by: Andrew Price <anprice@redhat.com>
---
fs/gfs2/ops_fstype.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/gfs2/ops_fstype.c b/fs/gfs2/ops_fstype.c
index 681b44682b0d..dc61af2c4d5e 100644
--- a/fs/gfs2/ops_fstype.c
+++ b/fs/gfs2/ops_fstype.c
@@ -1600,6 +1600,7 @@ static int gfs2_meta_get_tree(struct fs_context *fc)
}
static const struct fs_context_operations gfs2_meta_context_ops = {
+ .free = gfs2_fc_free,
.get_tree = gfs2_meta_get_tree,
};
--
2.21.0
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [Cluster-devel] [PATCH] gfs2: Fix memory leak when gfs2meta's fs_context is freed
2019-10-03 15:35 ` [Cluster-devel] " Andrew Price
@ 2019-10-04 17:20 ` Bob Peterson
-1 siblings, 0 replies; 8+ messages in thread
From: Bob Peterson @ 2019-10-04 17:20 UTC (permalink / raw)
To: Andrew Price
Cc: cluster-devel, syzbot+c2fdfd2b783754878fb6, syzkaller-bugs, linux-kernel
----- Original Message -----
> gfs2 and gfs2meta share an ->init_fs_context function which allocates an
> args structure stored in fc->fs_private. gfs2 registers a ->free
> function to free this memory when the fs_context is cleaned up, but
> there was not one registered for gfs2meta, causing a leak.
>
> Register a ->free function for gfs2meta. The existing gfs2_fc_free
> function does what we need.
>
> Reported-by: syzbot+c2fdfd2b783754878fb6@syzkaller.appspotmail.com
> Signed-off-by: Andrew Price <anprice@redhat.com>
> ---
Thanks. Now pushed to for-next.
Bob Peterson
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Cluster-devel] [PATCH] gfs2: Fix memory leak when gfs2meta's fs_context is freed
@ 2019-10-04 17:20 ` Bob Peterson
0 siblings, 0 replies; 8+ messages in thread
From: Bob Peterson @ 2019-10-04 17:20 UTC (permalink / raw)
To: cluster-devel.redhat.com
----- Original Message -----
> gfs2 and gfs2meta share an ->init_fs_context function which allocates an
> args structure stored in fc->fs_private. gfs2 registers a ->free
> function to free this memory when the fs_context is cleaned up, but
> there was not one registered for gfs2meta, causing a leak.
>
> Register a ->free function for gfs2meta. The existing gfs2_fc_free
> function does what we need.
>
> Reported-by: syzbot+c2fdfd2b783754878fb6 at syzkaller.appspotmail.com
> Signed-off-by: Andrew Price <anprice@redhat.com>
> ---
Thanks. Now pushed to for-next.
Bob Peterson
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Cluster-devel] [PATCH] gfs2: Fix memory leak when gfs2meta's fs_context is freed
2019-10-04 17:20 ` Bob Peterson
(?)
@ 2019-10-09 6:36 ` Andrew Price
2019-10-23 10:12 ` Andrew Price
-1 siblings, 1 reply; 8+ messages in thread
From: Andrew Price @ 2019-10-09 6:36 UTC (permalink / raw)
To: cluster-devel.redhat.com
On 04/10/2019 18:20, Bob Peterson wrote:
> ----- Original Message -----
>> gfs2 and gfs2meta share an ->init_fs_context function which allocates an
>> args structure stored in fc->fs_private. gfs2 registers a ->free
>> function to free this memory when the fs_context is cleaned up, but
>> there was not one registered for gfs2meta, causing a leak.
>>
>> Register a ->free function for gfs2meta. The existing gfs2_fc_free
>> function does what we need.
>>
>> Reported-by: syzbot+c2fdfd2b783754878fb6 at syzkaller.appspotmail.com
>> Signed-off-by: Andrew Price <anprice@redhat.com>
>> ---
>
> Thanks. Now pushed to for-next.
Thanks Bob. Can we get this sent to Linus as a fix during this cycle?
Andy
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Cluster-devel] [PATCH] gfs2: Fix memory leak when gfs2meta's fs_context is freed
2019-10-09 6:36 ` Andrew Price
@ 2019-10-23 10:12 ` Andrew Price
0 siblings, 0 replies; 8+ messages in thread
From: Andrew Price @ 2019-10-23 10:12 UTC (permalink / raw)
To: cluster-devel.redhat.com
On 09/10/2019 07:36, Andrew Price wrote:
> On 04/10/2019 18:20, Bob Peterson wrote:
>> ----- Original Message -----
>>> gfs2 and gfs2meta share an ->init_fs_context function which allocates an
>>> args structure stored in fc->fs_private. gfs2 registers a ->free
>>> function to free this memory when the fs_context is cleaned up, but
>>> there was not one registered for gfs2meta, causing a leak.
>>>
>>> Register a ->free function for gfs2meta. The existing gfs2_fc_free
>>> function does what we need.
>>>
>>> Reported-by: syzbot+c2fdfd2b783754878fb6 at syzkaller.appspotmail.com
>>> Signed-off-by: Andrew Price <anprice@redhat.com>
>>> ---
>>
>> Thanks. Now pushed to for-next.
>
> Thanks Bob. Can we get this sent to Linus as a fix during this cycle?
>
> Andy
>
It might need a
Fixes: 1f52aa08d12f8d359e71b4bfd73ca9d5d668e4da
That commit went upstream during this cycle's merge window so if we can
get the fix upstream before release we won't have to worry about stable.
Andy
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-10-23 10:12 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-03 0:19 memory leak in gfs2_init_fs_context syzbot
2019-10-03 0:19 ` [Cluster-devel] " syzbot
2019-10-03 15:35 ` [PATCH] gfs2: Fix memory leak when gfs2meta's fs_context is freed Andrew Price
2019-10-03 15:35 ` [Cluster-devel] " Andrew Price
2019-10-04 17:20 ` Bob Peterson
2019-10-04 17:20 ` Bob Peterson
2019-10-09 6:36 ` Andrew Price
2019-10-23 10:12 ` Andrew Price
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.