* memory leak in sctp_stream_init_ext
@ 2019-05-31 14:58 syzbot
2019-06-04 13:36 ` Xin Long
0 siblings, 1 reply; 7+ messages in thread
From: syzbot @ 2019-05-31 14:58 UTC (permalink / raw)
To: davem, linux-kernel, linux-sctp, marcelo.leitner, netdev,
nhorman, syzkaller-bugs, vyasevich
Hello,
syzbot found the following crash on:
HEAD commit: bec7550c Merge tag 'docs-5.2-fixes2' of git://git.lwn.net/..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=152a0916a00000
kernel config: https://syzkaller.appspot.com/x/.config?x=64479170dcaf0e11
dashboard link: https://syzkaller.appspot.com/bug?extid=7f3b6b106be8dcdcdeec
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1142cd4ca00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10f81d72a00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+7f3b6b106be8dcdcdeec@syzkaller.appspotmail.com
executing program
executing program
executing program
executing program
executing program
BUG: memory leak
unreferenced object 0xffff8881114f5d80 (size 96):
comm "syz-executor934", pid 7160, jiffies 4294993058 (age 31.950s)
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:
[<00000000ce7a1326>] kmemleak_alloc_recursive
include/linux/kmemleak.h:55 [inline]
[<00000000ce7a1326>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<00000000ce7a1326>] slab_alloc mm/slab.c:3326 [inline]
[<00000000ce7a1326>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
[<000000007abb7ac9>] kmalloc include/linux/slab.h:547 [inline]
[<000000007abb7ac9>] kzalloc include/linux/slab.h:742 [inline]
[<000000007abb7ac9>] sctp_stream_init_ext+0x2b/0xa0
net/sctp/stream.c:157
[<0000000048ecb9c1>] sctp_sendmsg_to_asoc+0x946/0xa00
net/sctp/socket.c:1882
[<000000004483ca2b>] sctp_sendmsg+0x2a8/0x990 net/sctp/socket.c:2102
[<0000000094bdc32e>] inet_sendmsg+0x64/0x120 net/ipv4/af_inet.c:802
[<0000000022d1c2a5>] sock_sendmsg_nosec net/socket.c:652 [inline]
[<0000000022d1c2a5>] sock_sendmsg+0x54/0x70 net/socket.c:671
[<000000006ab53119>] sock_write_iter+0xb6/0x130 net/socket.c:1000
[<00000000973772ef>] call_write_iter include/linux/fs.h:1872 [inline]
[<00000000973772ef>] new_sync_write+0x1ad/0x260 fs/read_write.c:483
[<0000000033f2491b>] __vfs_write+0x87/0xa0 fs/read_write.c:496
[<00000000372fbd56>] vfs_write fs/read_write.c:558 [inline]
[<00000000372fbd56>] vfs_write+0xee/0x210 fs/read_write.c:542
[<000000007ccb2ea5>] ksys_write+0x7c/0x130 fs/read_write.c:611
[<000000001c29b8c7>] __do_sys_write fs/read_write.c:623 [inline]
[<000000001c29b8c7>] __se_sys_write fs/read_write.c:620 [inline]
[<000000001c29b8c7>] __x64_sys_write+0x1e/0x30 fs/read_write.c:620
[<0000000014d9243b>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000059f6e9a8>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881114f5d80 (size 96):
comm "syz-executor934", pid 7160, jiffies 4294993058 (age 33.160s)
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:
[<00000000ce7a1326>] kmemleak_alloc_recursive
include/linux/kmemleak.h:55 [inline]
[<00000000ce7a1326>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<00000000ce7a1326>] slab_alloc mm/slab.c:3326 [inline]
[<00000000ce7a1326>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
[<000000007abb7ac9>] kmalloc include/linux/slab.h:547 [inline]
[<000000007abb7ac9>] kzalloc include/linux/slab.h:742 [inline]
[<000000007abb7ac9>] sctp_stream_init_ext+0x2b/0xa0
net/sctp/stream.c:157
[<0000000048ecb9c1>] sctp_sendmsg_to_asoc+0x946/0xa00
net/sctp/socket.c:1882
[<000000004483ca2b>] sctp_sendmsg+0x2a8/0x990 net/sctp/socket.c:2102
[<0000000094bdc32e>] inet_sendmsg+0x64/0x120 net/ipv4/af_inet.c:802
[<0000000022d1c2a5>] sock_sendmsg_nosec net/socket.c:652 [inline]
[<0000000022d1c2a5>] sock_sendmsg+0x54/0x70 net/socket.c:671
[<000000006ab53119>] sock_write_iter+0xb6/0x130 net/socket.c:1000
[<00000000973772ef>] call_write_iter include/linux/fs.h:1872 [inline]
[<00000000973772ef>] new_sync_write+0x1ad/0x260 fs/read_write.c:483
[<0000000033f2491b>] __vfs_write+0x87/0xa0 fs/read_write.c:496
[<00000000372fbd56>] vfs_write fs/read_write.c:558 [inline]
[<00000000372fbd56>] vfs_write+0xee/0x210 fs/read_write.c:542
[<000000007ccb2ea5>] ksys_write+0x7c/0x130 fs/read_write.c:611
[<000000001c29b8c7>] __do_sys_write fs/read_write.c:623 [inline]
[<000000001c29b8c7>] __se_sys_write fs/read_write.c:620 [inline]
[<000000001c29b8c7>] __x64_sys_write+0x1e/0x30 fs/read_write.c:620
[<0000000014d9243b>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:301
[<0000000059f6e9a8>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
executing program
executing program
executing program
executing program
executing program
executing program
---
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] 7+ messages in thread* Re: memory leak in sctp_stream_init_ext 2019-05-31 14:58 memory leak in sctp_stream_init_ext syzbot @ 2019-06-04 13:36 ` Xin Long 2019-06-04 13:38 ` Dmitry Vyukov 0 siblings, 1 reply; 7+ messages in thread From: Xin Long @ 2019-06-04 13:36 UTC (permalink / raw) To: syzbot Cc: davem, LKML, linux-sctp, Marcelo Ricardo Leitner, network dev, Neil Horman, syzkaller-bugs, Vlad Yasevich On Fri, May 31, 2019 at 10:59 PM syzbot <syzbot+7f3b6b106be8dcdcdeec@syzkaller.appspotmail.com> wrote: > > Hello, > > syzbot found the following crash on: > > HEAD commit: bec7550c Merge tag 'docs-5.2-fixes2' of git://git.lwn.net/.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=152a0916a00000 > kernel config: https://syzkaller.appspot.com/x/.config?x=64479170dcaf0e11 > dashboard link: https://syzkaller.appspot.com/bug?extid=7f3b6b106be8dcdcdeec > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1142cd4ca00000 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10f81d72a00000 > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+7f3b6b106be8dcdcdeec@syzkaller.appspotmail.com > > executing program > executing program > executing program > executing program > executing program > BUG: memory leak > unreferenced object 0xffff8881114f5d80 (size 96): > comm "syz-executor934", pid 7160, jiffies 4294993058 (age 31.950s) > 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: > [<00000000ce7a1326>] kmemleak_alloc_recursive > include/linux/kmemleak.h:55 [inline] > [<00000000ce7a1326>] slab_post_alloc_hook mm/slab.h:439 [inline] > [<00000000ce7a1326>] slab_alloc mm/slab.c:3326 [inline] > [<00000000ce7a1326>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553 > [<000000007abb7ac9>] kmalloc include/linux/slab.h:547 [inline] > [<000000007abb7ac9>] kzalloc include/linux/slab.h:742 [inline] > [<000000007abb7ac9>] sctp_stream_init_ext+0x2b/0xa0 > net/sctp/stream.c:157 > [<0000000048ecb9c1>] sctp_sendmsg_to_asoc+0x946/0xa00 > net/sctp/socket.c:1882 is this possible to be a false positive? As in my testing, I tracked the objects allocated by "sctp_sendmsg_to_asoc () -> sctp_stream_init_ext()." all of them got freed properly in sctp_stream_free(), while this warning was still triggered. > [<000000004483ca2b>] sctp_sendmsg+0x2a8/0x990 net/sctp/socket.c:2102 > [<0000000094bdc32e>] inet_sendmsg+0x64/0x120 net/ipv4/af_inet.c:802 > [<0000000022d1c2a5>] sock_sendmsg_nosec net/socket.c:652 [inline] > [<0000000022d1c2a5>] sock_sendmsg+0x54/0x70 net/socket.c:671 > [<000000006ab53119>] sock_write_iter+0xb6/0x130 net/socket.c:1000 > [<00000000973772ef>] call_write_iter include/linux/fs.h:1872 [inline] > [<00000000973772ef>] new_sync_write+0x1ad/0x260 fs/read_write.c:483 > [<0000000033f2491b>] __vfs_write+0x87/0xa0 fs/read_write.c:496 > [<00000000372fbd56>] vfs_write fs/read_write.c:558 [inline] > [<00000000372fbd56>] vfs_write+0xee/0x210 fs/read_write.c:542 > [<000000007ccb2ea5>] ksys_write+0x7c/0x130 fs/read_write.c:611 > [<000000001c29b8c7>] __do_sys_write fs/read_write.c:623 [inline] > [<000000001c29b8c7>] __se_sys_write fs/read_write.c:620 [inline] > [<000000001c29b8c7>] __x64_sys_write+0x1e/0x30 fs/read_write.c:620 > [<0000000014d9243b>] do_syscall_64+0x76/0x1a0 > arch/x86/entry/common.c:301 > [<0000000059f6e9a8>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > BUG: memory leak > unreferenced object 0xffff8881114f5d80 (size 96): > comm "syz-executor934", pid 7160, jiffies 4294993058 (age 33.160s) > 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: > [<00000000ce7a1326>] kmemleak_alloc_recursive > include/linux/kmemleak.h:55 [inline] > [<00000000ce7a1326>] slab_post_alloc_hook mm/slab.h:439 [inline] > [<00000000ce7a1326>] slab_alloc mm/slab.c:3326 [inline] > [<00000000ce7a1326>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553 > [<000000007abb7ac9>] kmalloc include/linux/slab.h:547 [inline] > [<000000007abb7ac9>] kzalloc include/linux/slab.h:742 [inline] > [<000000007abb7ac9>] sctp_stream_init_ext+0x2b/0xa0 > net/sctp/stream.c:157 > [<0000000048ecb9c1>] sctp_sendmsg_to_asoc+0x946/0xa00 > net/sctp/socket.c:1882 > [<000000004483ca2b>] sctp_sendmsg+0x2a8/0x990 net/sctp/socket.c:2102 > [<0000000094bdc32e>] inet_sendmsg+0x64/0x120 net/ipv4/af_inet.c:802 > [<0000000022d1c2a5>] sock_sendmsg_nosec net/socket.c:652 [inline] > [<0000000022d1c2a5>] sock_sendmsg+0x54/0x70 net/socket.c:671 > [<000000006ab53119>] sock_write_iter+0xb6/0x130 net/socket.c:1000 > [<00000000973772ef>] call_write_iter include/linux/fs.h:1872 [inline] > [<00000000973772ef>] new_sync_write+0x1ad/0x260 fs/read_write.c:483 > [<0000000033f2491b>] __vfs_write+0x87/0xa0 fs/read_write.c:496 > [<00000000372fbd56>] vfs_write fs/read_write.c:558 [inline] > [<00000000372fbd56>] vfs_write+0xee/0x210 fs/read_write.c:542 > [<000000007ccb2ea5>] ksys_write+0x7c/0x130 fs/read_write.c:611 > [<000000001c29b8c7>] __do_sys_write fs/read_write.c:623 [inline] > [<000000001c29b8c7>] __se_sys_write fs/read_write.c:620 [inline] > [<000000001c29b8c7>] __x64_sys_write+0x1e/0x30 fs/read_write.c:620 > [<0000000014d9243b>] do_syscall_64+0x76/0x1a0 > arch/x86/entry/common.c:301 > [<0000000059f6e9a8>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > executing program > executing program > executing program > executing program > executing program > executing program > > > --- > 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] 7+ messages in thread
* Re: memory leak in sctp_stream_init_ext 2019-06-04 13:36 ` Xin Long @ 2019-06-04 13:38 ` Dmitry Vyukov 2019-10-04 6:50 ` [PATCH] lib/generic-radix-tree.c: add kmemleak annotations Eric Biggers 0 siblings, 1 reply; 7+ messages in thread From: Dmitry Vyukov @ 2019-06-04 13:38 UTC (permalink / raw) To: Xin Long Cc: syzbot, davem, LKML, linux-sctp, Marcelo Ricardo Leitner, network dev, Neil Horman, syzkaller-bugs, Vlad Yasevich On Tue, Jun 4, 2019 at 3:37 PM Xin Long <lucien.xin@gmail.com> wrote: > > On Fri, May 31, 2019 at 10:59 PM syzbot > <syzbot+7f3b6b106be8dcdcdeec@syzkaller.appspotmail.com> wrote: > > > > Hello, > > > > syzbot found the following crash on: > > > > HEAD commit: bec7550c Merge tag 'docs-5.2-fixes2' of git://git.lwn.net/.. > > git tree: upstream > > console output: https://syzkaller.appspot.com/x/log.txt?x=152a0916a00000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=64479170dcaf0e11 > > dashboard link: https://syzkaller.appspot.com/bug?extid=7f3b6b106be8dcdcdeec > > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1142cd4ca00000 > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10f81d72a00000 > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > Reported-by: syzbot+7f3b6b106be8dcdcdeec@syzkaller.appspotmail.com > > > > executing program > > executing program > > executing program > > executing program > > executing program > > BUG: memory leak > > unreferenced object 0xffff8881114f5d80 (size 96): > > comm "syz-executor934", pid 7160, jiffies 4294993058 (age 31.950s) > > 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: > > [<00000000ce7a1326>] kmemleak_alloc_recursive > > include/linux/kmemleak.h:55 [inline] > > [<00000000ce7a1326>] slab_post_alloc_hook mm/slab.h:439 [inline] > > [<00000000ce7a1326>] slab_alloc mm/slab.c:3326 [inline] > > [<00000000ce7a1326>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553 > > [<000000007abb7ac9>] kmalloc include/linux/slab.h:547 [inline] > > [<000000007abb7ac9>] kzalloc include/linux/slab.h:742 [inline] > > [<000000007abb7ac9>] sctp_stream_init_ext+0x2b/0xa0 > > net/sctp/stream.c:157 > > [<0000000048ecb9c1>] sctp_sendmsg_to_asoc+0x946/0xa00 > > net/sctp/socket.c:1882 > > is this possible to be a false positive? https://goo.gl/tpsmEJ#memory-leaks > As in my testing, I tracked the objects allocated by > "sctp_sendmsg_to_asoc () -> sctp_stream_init_ext()." > all of them got freed properly in sctp_stream_free(), > while this warning was still triggered. > > > [<000000004483ca2b>] sctp_sendmsg+0x2a8/0x990 net/sctp/socket.c:2102 > > [<0000000094bdc32e>] inet_sendmsg+0x64/0x120 net/ipv4/af_inet.c:802 > > [<0000000022d1c2a5>] sock_sendmsg_nosec net/socket.c:652 [inline] > > [<0000000022d1c2a5>] sock_sendmsg+0x54/0x70 net/socket.c:671 > > [<000000006ab53119>] sock_write_iter+0xb6/0x130 net/socket.c:1000 > > [<00000000973772ef>] call_write_iter include/linux/fs.h:1872 [inline] > > [<00000000973772ef>] new_sync_write+0x1ad/0x260 fs/read_write.c:483 > > [<0000000033f2491b>] __vfs_write+0x87/0xa0 fs/read_write.c:496 > > [<00000000372fbd56>] vfs_write fs/read_write.c:558 [inline] > > [<00000000372fbd56>] vfs_write+0xee/0x210 fs/read_write.c:542 > > [<000000007ccb2ea5>] ksys_write+0x7c/0x130 fs/read_write.c:611 > > [<000000001c29b8c7>] __do_sys_write fs/read_write.c:623 [inline] > > [<000000001c29b8c7>] __se_sys_write fs/read_write.c:620 [inline] > > [<000000001c29b8c7>] __x64_sys_write+0x1e/0x30 fs/read_write.c:620 > > [<0000000014d9243b>] do_syscall_64+0x76/0x1a0 > > arch/x86/entry/common.c:301 > > [<0000000059f6e9a8>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > > BUG: memory leak > > unreferenced object 0xffff8881114f5d80 (size 96): > > comm "syz-executor934", pid 7160, jiffies 4294993058 (age 33.160s) > > 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: > > [<00000000ce7a1326>] kmemleak_alloc_recursive > > include/linux/kmemleak.h:55 [inline] > > [<00000000ce7a1326>] slab_post_alloc_hook mm/slab.h:439 [inline] > > [<00000000ce7a1326>] slab_alloc mm/slab.c:3326 [inline] > > [<00000000ce7a1326>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553 > > [<000000007abb7ac9>] kmalloc include/linux/slab.h:547 [inline] > > [<000000007abb7ac9>] kzalloc include/linux/slab.h:742 [inline] > > [<000000007abb7ac9>] sctp_stream_init_ext+0x2b/0xa0 > > net/sctp/stream.c:157 > > [<0000000048ecb9c1>] sctp_sendmsg_to_asoc+0x946/0xa00 > > net/sctp/socket.c:1882 > > [<000000004483ca2b>] sctp_sendmsg+0x2a8/0x990 net/sctp/socket.c:2102 > > [<0000000094bdc32e>] inet_sendmsg+0x64/0x120 net/ipv4/af_inet.c:802 > > [<0000000022d1c2a5>] sock_sendmsg_nosec net/socket.c:652 [inline] > > [<0000000022d1c2a5>] sock_sendmsg+0x54/0x70 net/socket.c:671 > > [<000000006ab53119>] sock_write_iter+0xb6/0x130 net/socket.c:1000 > > [<00000000973772ef>] call_write_iter include/linux/fs.h:1872 [inline] > > [<00000000973772ef>] new_sync_write+0x1ad/0x260 fs/read_write.c:483 > > [<0000000033f2491b>] __vfs_write+0x87/0xa0 fs/read_write.c:496 > > [<00000000372fbd56>] vfs_write fs/read_write.c:558 [inline] > > [<00000000372fbd56>] vfs_write+0xee/0x210 fs/read_write.c:542 > > [<000000007ccb2ea5>] ksys_write+0x7c/0x130 fs/read_write.c:611 > > [<000000001c29b8c7>] __do_sys_write fs/read_write.c:623 [inline] > > [<000000001c29b8c7>] __se_sys_write fs/read_write.c:620 [inline] > > [<000000001c29b8c7>] __x64_sys_write+0x1e/0x30 fs/read_write.c:620 > > [<0000000014d9243b>] do_syscall_64+0x76/0x1a0 > > arch/x86/entry/common.c:301 > > [<0000000059f6e9a8>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > > executing program > > executing program > > executing program > > executing program > > executing program > > executing program > > > > > > --- > > 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 > > -- > You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/CADvbK_evGyJZaUQZa6U26tJSQCNW4jb3uqLWGQGF_7HJgv-Sog%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH] lib/generic-radix-tree.c: add kmemleak annotations 2019-06-04 13:38 ` Dmitry Vyukov @ 2019-10-04 6:50 ` Eric Biggers 2019-10-04 12:21 ` Marcelo Ricardo Leitner ` (2 more replies) 0 siblings, 3 replies; 7+ messages in thread From: Eric Biggers @ 2019-10-04 6:50 UTC (permalink / raw) To: Andrew Morton Cc: linux-mm, linux-sctp, linux-kernel, syzkaller-bugs, Catalin Marinas, Kent Overstreet, Vlad Yasevich, Xin Long, Neil Horman, Marcelo Ricardo Leitner From: Eric Biggers <ebiggers@google.com> Kmemleak is falsely reporting a leak of the slab allocation in sctp_stream_init_ext(): BUG: memory leak unreferenced object 0xffff8881114f5d80 (size 96): comm "syz-executor934", pid 7160, jiffies 4294993058 (age 31.950s) 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: [<00000000ce7a1326>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline] [<00000000ce7a1326>] slab_post_alloc_hook mm/slab.h:439 [inline] [<00000000ce7a1326>] slab_alloc mm/slab.c:3326 [inline] [<00000000ce7a1326>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553 [<000000007abb7ac9>] kmalloc include/linux/slab.h:547 [inline] [<000000007abb7ac9>] kzalloc include/linux/slab.h:742 [inline] [<000000007abb7ac9>] sctp_stream_init_ext+0x2b/0xa0 net/sctp/stream.c:157 [<0000000048ecb9c1>] sctp_sendmsg_to_asoc+0x946/0xa00 net/sctp/socket.c:1882 [<000000004483ca2b>] sctp_sendmsg+0x2a8/0x990 net/sctp/socket.c:2102 [...] But it's freed later. Kmemleak misses the allocation because its pointer is stored in the generic radix tree sctp_stream::out, and the generic radix tree uses raw pages which aren't tracked by kmemleak. Fix this by adding the kmemleak hooks to the generic radix tree code. Reported-by: syzbot+7f3b6b106be8dcdcdeec@syzkaller.appspotmail.com Signed-off-by: Eric Biggers <ebiggers@google.com> --- lib/generic-radix-tree.c | 32 ++++++++++++++++++++++++++------ 1 file changed, 26 insertions(+), 6 deletions(-) diff --git a/lib/generic-radix-tree.c b/lib/generic-radix-tree.c index ae25e2fa2187..f25eb111c051 100644 --- a/lib/generic-radix-tree.c +++ b/lib/generic-radix-tree.c @@ -2,6 +2,7 @@ #include <linux/export.h> #include <linux/generic-radix-tree.h> #include <linux/gfp.h> +#include <linux/kmemleak.h> #define GENRADIX_ARY (PAGE_SIZE / sizeof(struct genradix_node *)) #define GENRADIX_ARY_SHIFT ilog2(GENRADIX_ARY) @@ -75,6 +76,27 @@ void *__genradix_ptr(struct __genradix *radix, size_t offset) } EXPORT_SYMBOL(__genradix_ptr); +static inline struct genradix_node *genradix_alloc_node(gfp_t gfp_mask) +{ + struct genradix_node *node; + + node = (struct genradix_node *)__get_free_page(gfp_mask|__GFP_ZERO); + + /* + * We're using pages (not slab allocations) directly for kernel data + * structures, so we need to explicitly inform kmemleak of them in order + * to avoid false positive memory leak reports. + */ + kmemleak_alloc(node, PAGE_SIZE, 1, gfp_mask); + return node; +} + +static inline void genradix_free_node(struct genradix_node *node) +{ + kmemleak_free(node); + free_page((unsigned long)node); +} + /* * Returns pointer to the specified byte @offset within @radix, allocating it if * necessary - newly allocated slots are always zeroed out: @@ -97,8 +119,7 @@ void *__genradix_ptr_alloc(struct __genradix *radix, size_t offset, break; if (!new_node) { - new_node = (void *) - __get_free_page(gfp_mask|__GFP_ZERO); + new_node = genradix_alloc_node(gfp_mask); if (!new_node) return NULL; } @@ -121,8 +142,7 @@ void *__genradix_ptr_alloc(struct __genradix *radix, size_t offset, n = READ_ONCE(*p); if (!n) { if (!new_node) { - new_node = (void *) - __get_free_page(gfp_mask|__GFP_ZERO); + new_node = genradix_alloc_node(gfp_mask); if (!new_node) return NULL; } @@ -133,7 +153,7 @@ void *__genradix_ptr_alloc(struct __genradix *radix, size_t offset, } if (new_node) - free_page((unsigned long) new_node); + genradix_free_node(new_node); return &n->data[offset]; } @@ -191,7 +211,7 @@ static void genradix_free_recurse(struct genradix_node *n, unsigned level) genradix_free_recurse(n->children[i], level - 1); } - free_page((unsigned long) n); + genradix_free_node(n); } int __genradix_prealloc(struct __genradix *radix, size_t size, -- 2.23.0 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] lib/generic-radix-tree.c: add kmemleak annotations 2019-10-04 6:50 ` [PATCH] lib/generic-radix-tree.c: add kmemleak annotations Eric Biggers @ 2019-10-04 12:21 ` Marcelo Ricardo Leitner 2019-10-04 12:27 ` Neil Horman 2019-10-04 14:48 ` Catalin Marinas 2 siblings, 0 replies; 7+ messages in thread From: Marcelo Ricardo Leitner @ 2019-10-04 12:21 UTC (permalink / raw) To: Eric Biggers Cc: Andrew Morton, linux-mm, linux-sctp, linux-kernel, syzkaller-bugs, Catalin Marinas, Kent Overstreet, Vlad Yasevich, Xin Long, Neil Horman On Thu, Oct 03, 2019 at 11:50:39PM -0700, Eric Biggers wrote: > From: Eric Biggers <ebiggers@google.com> > > Kmemleak is falsely reporting a leak of the slab allocation in > sctp_stream_init_ext(): > > BUG: memory leak > unreferenced object 0xffff8881114f5d80 (size 96): > comm "syz-executor934", pid 7160, jiffies 4294993058 (age 31.950s) > 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: > [<00000000ce7a1326>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline] > [<00000000ce7a1326>] slab_post_alloc_hook mm/slab.h:439 [inline] > [<00000000ce7a1326>] slab_alloc mm/slab.c:3326 [inline] > [<00000000ce7a1326>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553 > [<000000007abb7ac9>] kmalloc include/linux/slab.h:547 [inline] > [<000000007abb7ac9>] kzalloc include/linux/slab.h:742 [inline] > [<000000007abb7ac9>] sctp_stream_init_ext+0x2b/0xa0 net/sctp/stream.c:157 > [<0000000048ecb9c1>] sctp_sendmsg_to_asoc+0x946/0xa00 net/sctp/socket.c:1882 > [<000000004483ca2b>] sctp_sendmsg+0x2a8/0x990 net/sctp/socket.c:2102 > [...] > > But it's freed later. Kmemleak misses the allocation because its > pointer is stored in the generic radix tree sctp_stream::out, and the > generic radix tree uses raw pages which aren't tracked by kmemleak. > > Fix this by adding the kmemleak hooks to the generic radix tree code. Nice, thanks Eric. Reviewed-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> > > Reported-by: syzbot+7f3b6b106be8dcdcdeec@syzkaller.appspotmail.com > Signed-off-by: Eric Biggers <ebiggers@google.com> > --- > lib/generic-radix-tree.c | 32 ++++++++++++++++++++++++++------ > 1 file changed, 26 insertions(+), 6 deletions(-) > > diff --git a/lib/generic-radix-tree.c b/lib/generic-radix-tree.c > index ae25e2fa2187..f25eb111c051 100644 > --- a/lib/generic-radix-tree.c > +++ b/lib/generic-radix-tree.c > @@ -2,6 +2,7 @@ > #include <linux/export.h> > #include <linux/generic-radix-tree.h> > #include <linux/gfp.h> > +#include <linux/kmemleak.h> > > #define GENRADIX_ARY (PAGE_SIZE / sizeof(struct genradix_node *)) > #define GENRADIX_ARY_SHIFT ilog2(GENRADIX_ARY) > @@ -75,6 +76,27 @@ void *__genradix_ptr(struct __genradix *radix, size_t offset) > } > EXPORT_SYMBOL(__genradix_ptr); > > +static inline struct genradix_node *genradix_alloc_node(gfp_t gfp_mask) > +{ > + struct genradix_node *node; > + > + node = (struct genradix_node *)__get_free_page(gfp_mask|__GFP_ZERO); > + > + /* > + * We're using pages (not slab allocations) directly for kernel data > + * structures, so we need to explicitly inform kmemleak of them in order > + * to avoid false positive memory leak reports. > + */ > + kmemleak_alloc(node, PAGE_SIZE, 1, gfp_mask); > + return node; > +} > + > +static inline void genradix_free_node(struct genradix_node *node) > +{ > + kmemleak_free(node); > + free_page((unsigned long)node); > +} > + > /* > * Returns pointer to the specified byte @offset within @radix, allocating it if > * necessary - newly allocated slots are always zeroed out: > @@ -97,8 +119,7 @@ void *__genradix_ptr_alloc(struct __genradix *radix, size_t offset, > break; > > if (!new_node) { > - new_node = (void *) > - __get_free_page(gfp_mask|__GFP_ZERO); > + new_node = genradix_alloc_node(gfp_mask); > if (!new_node) > return NULL; > } > @@ -121,8 +142,7 @@ void *__genradix_ptr_alloc(struct __genradix *radix, size_t offset, > n = READ_ONCE(*p); > if (!n) { > if (!new_node) { > - new_node = (void *) > - __get_free_page(gfp_mask|__GFP_ZERO); > + new_node = genradix_alloc_node(gfp_mask); > if (!new_node) > return NULL; > } > @@ -133,7 +153,7 @@ void *__genradix_ptr_alloc(struct __genradix *radix, size_t offset, > } > > if (new_node) > - free_page((unsigned long) new_node); > + genradix_free_node(new_node); > > return &n->data[offset]; > } > @@ -191,7 +211,7 @@ static void genradix_free_recurse(struct genradix_node *n, unsigned level) > genradix_free_recurse(n->children[i], level - 1); > } > > - free_page((unsigned long) n); > + genradix_free_node(n); > } > > int __genradix_prealloc(struct __genradix *radix, size_t size, > -- > 2.23.0 > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] lib/generic-radix-tree.c: add kmemleak annotations 2019-10-04 6:50 ` [PATCH] lib/generic-radix-tree.c: add kmemleak annotations Eric Biggers 2019-10-04 12:21 ` Marcelo Ricardo Leitner @ 2019-10-04 12:27 ` Neil Horman 2019-10-04 14:48 ` Catalin Marinas 2 siblings, 0 replies; 7+ messages in thread From: Neil Horman @ 2019-10-04 12:27 UTC (permalink / raw) To: Eric Biggers Cc: Andrew Morton, linux-mm, linux-sctp, linux-kernel, syzkaller-bugs, Catalin Marinas, Kent Overstreet, Vlad Yasevich, Xin Long, Marcelo Ricardo Leitner On Thu, Oct 03, 2019 at 11:50:39PM -0700, Eric Biggers wrote: > From: Eric Biggers <ebiggers@google.com> > > Kmemleak is falsely reporting a leak of the slab allocation in > sctp_stream_init_ext(): > > BUG: memory leak > unreferenced object 0xffff8881114f5d80 (size 96): > comm "syz-executor934", pid 7160, jiffies 4294993058 (age 31.950s) > 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: > [<00000000ce7a1326>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline] > [<00000000ce7a1326>] slab_post_alloc_hook mm/slab.h:439 [inline] > [<00000000ce7a1326>] slab_alloc mm/slab.c:3326 [inline] > [<00000000ce7a1326>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553 > [<000000007abb7ac9>] kmalloc include/linux/slab.h:547 [inline] > [<000000007abb7ac9>] kzalloc include/linux/slab.h:742 [inline] > [<000000007abb7ac9>] sctp_stream_init_ext+0x2b/0xa0 net/sctp/stream.c:157 > [<0000000048ecb9c1>] sctp_sendmsg_to_asoc+0x946/0xa00 net/sctp/socket.c:1882 > [<000000004483ca2b>] sctp_sendmsg+0x2a8/0x990 net/sctp/socket.c:2102 > [...] > > But it's freed later. Kmemleak misses the allocation because its > pointer is stored in the generic radix tree sctp_stream::out, and the > generic radix tree uses raw pages which aren't tracked by kmemleak. > > Fix this by adding the kmemleak hooks to the generic radix tree code. > > Reported-by: syzbot+7f3b6b106be8dcdcdeec@syzkaller.appspotmail.com > Signed-off-by: Eric Biggers <ebiggers@google.com> > --- > lib/generic-radix-tree.c | 32 ++++++++++++++++++++++++++------ > 1 file changed, 26 insertions(+), 6 deletions(-) > > diff --git a/lib/generic-radix-tree.c b/lib/generic-radix-tree.c > index ae25e2fa2187..f25eb111c051 100644 > --- a/lib/generic-radix-tree.c > +++ b/lib/generic-radix-tree.c > @@ -2,6 +2,7 @@ > #include <linux/export.h> > #include <linux/generic-radix-tree.h> > #include <linux/gfp.h> > +#include <linux/kmemleak.h> > > #define GENRADIX_ARY (PAGE_SIZE / sizeof(struct genradix_node *)) > #define GENRADIX_ARY_SHIFT ilog2(GENRADIX_ARY) > @@ -75,6 +76,27 @@ void *__genradix_ptr(struct __genradix *radix, size_t offset) > } > EXPORT_SYMBOL(__genradix_ptr); > > +static inline struct genradix_node *genradix_alloc_node(gfp_t gfp_mask) > +{ > + struct genradix_node *node; > + > + node = (struct genradix_node *)__get_free_page(gfp_mask|__GFP_ZERO); > + > + /* > + * We're using pages (not slab allocations) directly for kernel data > + * structures, so we need to explicitly inform kmemleak of them in order > + * to avoid false positive memory leak reports. > + */ > + kmemleak_alloc(node, PAGE_SIZE, 1, gfp_mask); > + return node; > +} > + > +static inline void genradix_free_node(struct genradix_node *node) > +{ > + kmemleak_free(node); > + free_page((unsigned long)node); > +} > + > /* > * Returns pointer to the specified byte @offset within @radix, allocating it if > * necessary - newly allocated slots are always zeroed out: > @@ -97,8 +119,7 @@ void *__genradix_ptr_alloc(struct __genradix *radix, size_t offset, > break; > > if (!new_node) { > - new_node = (void *) > - __get_free_page(gfp_mask|__GFP_ZERO); > + new_node = genradix_alloc_node(gfp_mask); > if (!new_node) > return NULL; > } > @@ -121,8 +142,7 @@ void *__genradix_ptr_alloc(struct __genradix *radix, size_t offset, > n = READ_ONCE(*p); > if (!n) { > if (!new_node) { > - new_node = (void *) > - __get_free_page(gfp_mask|__GFP_ZERO); > + new_node = genradix_alloc_node(gfp_mask); > if (!new_node) > return NULL; > } > @@ -133,7 +153,7 @@ void *__genradix_ptr_alloc(struct __genradix *radix, size_t offset, > } > > if (new_node) > - free_page((unsigned long) new_node); > + genradix_free_node(new_node); > > return &n->data[offset]; > } > @@ -191,7 +211,7 @@ static void genradix_free_recurse(struct genradix_node *n, unsigned level) > genradix_free_recurse(n->children[i], level - 1); > } > > - free_page((unsigned long) n); > + genradix_free_node(n); > } > > int __genradix_prealloc(struct __genradix *radix, size_t size, > -- > 2.23.0 > > Acked-by: Neil Horman <nhorman@tuxdriver.com> ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] lib/generic-radix-tree.c: add kmemleak annotations 2019-10-04 6:50 ` [PATCH] lib/generic-radix-tree.c: add kmemleak annotations Eric Biggers 2019-10-04 12:21 ` Marcelo Ricardo Leitner 2019-10-04 12:27 ` Neil Horman @ 2019-10-04 14:48 ` Catalin Marinas 2 siblings, 0 replies; 7+ messages in thread From: Catalin Marinas @ 2019-10-04 14:48 UTC (permalink / raw) To: Eric Biggers Cc: Andrew Morton, linux-mm, linux-sctp, linux-kernel, syzkaller-bugs, Kent Overstreet, Vlad Yasevich, Xin Long, Neil Horman, Marcelo Ricardo Leitner On Thu, Oct 03, 2019 at 11:50:39PM -0700, Eric Biggers wrote: > From: Eric Biggers <ebiggers@google.com> > > Kmemleak is falsely reporting a leak of the slab allocation in > sctp_stream_init_ext(): > > BUG: memory leak > unreferenced object 0xffff8881114f5d80 (size 96): > comm "syz-executor934", pid 7160, jiffies 4294993058 (age 31.950s) > 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: > [<00000000ce7a1326>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline] > [<00000000ce7a1326>] slab_post_alloc_hook mm/slab.h:439 [inline] > [<00000000ce7a1326>] slab_alloc mm/slab.c:3326 [inline] > [<00000000ce7a1326>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553 > [<000000007abb7ac9>] kmalloc include/linux/slab.h:547 [inline] > [<000000007abb7ac9>] kzalloc include/linux/slab.h:742 [inline] > [<000000007abb7ac9>] sctp_stream_init_ext+0x2b/0xa0 net/sctp/stream.c:157 > [<0000000048ecb9c1>] sctp_sendmsg_to_asoc+0x946/0xa00 net/sctp/socket.c:1882 > [<000000004483ca2b>] sctp_sendmsg+0x2a8/0x990 net/sctp/socket.c:2102 > [...] > > But it's freed later. Kmemleak misses the allocation because its > pointer is stored in the generic radix tree sctp_stream::out, and the > generic radix tree uses raw pages which aren't tracked by kmemleak. > > Fix this by adding the kmemleak hooks to the generic radix tree code. > > Reported-by: syzbot+7f3b6b106be8dcdcdeec@syzkaller.appspotmail.com > Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-10-04 14:48 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-05-31 14:58 memory leak in sctp_stream_init_ext syzbot 2019-06-04 13:36 ` Xin Long 2019-06-04 13:38 ` Dmitry Vyukov 2019-10-04 6:50 ` [PATCH] lib/generic-radix-tree.c: add kmemleak annotations Eric Biggers 2019-10-04 12:21 ` Marcelo Ricardo Leitner 2019-10-04 12:27 ` Neil Horman 2019-10-04 14:48 ` Catalin Marinas
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).