* net/sctp: sock memory leak
@ 2015-12-30 20:42 Dmitry Vyukov
2015-12-30 20:47 ` Marcelo Ricardo Leitner
2016-01-15 18:46 ` Marcelo Ricardo Leitner
0 siblings, 2 replies; 6+ messages in thread
From: Dmitry Vyukov @ 2015-12-30 20:42 UTC (permalink / raw)
To: Vlad Yasevich, Neil Horman, David S. Miller, linux-sctp, netdev,
LKML
Cc: syzkaller, Kostya Serebryany, Alexander Potapenko, Sasha Levin,
Eric Dumazet
Hello,
The following program leads to a leak of two sock objects:
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include <unistd.h>
#include <sys/syscall.h>
#include <string.h>
#include <stdint.h>
#include <pthread.h>
int fd;
void *thr(void *arg)
{
memcpy((void*)0x2000bbbe,
"\x0a\x00\x33\xdc\x14\x4d\x5b\xd1\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\xdd\x01\xf8\xfd\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00",
128);
syscall(SYS_sendto, fd, 0x2000b000ul, 0x70ul, 0x8000ul,
0x2000bbbeul, 0x80ul);
return 0;
}
int main()
{
long i;
pthread_t th[6];
syscall(SYS_mmap, 0x20000000ul, 0x20000ul, 0x3ul, 0x32ul,
0xfffffffffffffffful, 0x0ul);
fd = syscall(SYS_socket, 0xaul, 0x1ul, 0x84ul, 0, 0, 0);
memcpy((void*)0x20003000,
"\x02\x00\x33\xdf\x7f\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00",
128);
syscall(SYS_bind, fd, 0x20003000ul, 0x80ul, 0, 0, 0);
pthread_create(&th[0], 0, thr, (void*)0);
usleep(100000);
syscall(SYS_listen, fd, 0x3ul, 0, 0, 0, 0);
syscall(SYS_accept, fd, 0x20005f80ul, 0x20003000ul, 0, 0, 0);
return 0;
}
unreferenced object 0xffff8800342540c0 (size 1864):
comm "a.out", pid 24109, jiffies 4299060398 (age 27.984s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0a 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............
backtrace:
[<ffffffff85c73a22>] kmemleak_alloc+0x72/0xc0 mm/kmemleak.c:915
[< inline >] kmemleak_alloc_recursive include/linux/kmemleak.h:47
[< inline >] slab_post_alloc_hook mm/slub.c:1335
[< inline >] slab_alloc_node mm/slub.c:2594
[< inline >] slab_alloc mm/slub.c:2602
[<ffffffff816cc14d>] kmem_cache_alloc+0x12d/0x2c0 mm/slub.c:2607
[<ffffffff84b642c9>] sk_prot_alloc+0x69/0x340 net/core/sock.c:1344
[<ffffffff84b6d36a>] sk_alloc+0x3a/0x6b0 net/core/sock.c:1419
[<ffffffff850c6d57>] inet6_create+0x2d7/0x1000 net/ipv6/af_inet6.c:173
[<ffffffff84b5f47c>] __sock_create+0x37c/0x640 net/socket.c:1162
[< inline >] sock_create net/socket.c:1202
[< inline >] SYSC_socket net/socket.c:1232
[<ffffffff84b5f96f>] SyS_socket+0xef/0x1b0 net/socket.c:1212
[<ffffffff85c8eaf6>] entry_SYSCALL_64_fastpath+0x16/0x7a
arch/x86/entry/entry_64.S:185
[<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff880034253780 (size 1864):
comm "a.out", pid 24109, jiffies 4299060500 (age 27.882s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 33 dc 00 00 ............3...
0a 00 07 40 00 00 00 00 d8 40 25 34 00 88 ff ff ...@.....@%4....
backtrace:
[<ffffffff85c73a22>] kmemleak_alloc+0x72/0xc0 mm/kmemleak.c:915
[< inline >] kmemleak_alloc_recursive include/linux/kmemleak.h:47
[< inline >] slab_post_alloc_hook mm/slub.c:1335
[< inline >] slab_alloc_node mm/slub.c:2594
[< inline >] slab_alloc mm/slub.c:2602
[<ffffffff816cc14d>] kmem_cache_alloc+0x12d/0x2c0 mm/slub.c:2607
[<ffffffff84b642c9>] sk_prot_alloc+0x69/0x340 net/core/sock.c:1344
[<ffffffff84b6d36a>] sk_alloc+0x3a/0x6b0 net/core/sock.c:1419
[<ffffffff85750e00>] sctp_v6_create_accept_sk+0xf0/0x790 net/sctp/ipv6.c:646
[<ffffffff857242a9>] sctp_accept+0x409/0x6d0 net/sctp/socket.c:3925
[<ffffffff84fa33b3>] inet_accept+0xe3/0x660 net/ipv4/af_inet.c:671
[<ffffffff84b5a68c>] SYSC_accept4+0x32c/0x630 net/socket.c:1474
[< inline >] SyS_accept4 net/socket.c:1424
[< inline >] SYSC_accept net/socket.c:1508
[<ffffffff84b601e6>] SyS_accept+0x26/0x30 net/socket.c:1505
[<ffffffff85c8eaf6>] entry_SYSCALL_64_fastpath+0x16/0x7a
arch/x86/entry/entry_64.S:185
[<ffffffffffffffff>] 0xffffffffffffffff
On commit 8513342170278468bac126640a5d2d12ffbff106 (Dec 28).
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: net/sctp: sock memory leak
2015-12-30 20:42 net/sctp: sock memory leak Dmitry Vyukov
@ 2015-12-30 20:47 ` Marcelo Ricardo Leitner
2016-01-15 18:46 ` Marcelo Ricardo Leitner
1 sibling, 0 replies; 6+ messages in thread
From: Marcelo Ricardo Leitner @ 2015-12-30 20:47 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Vlad Yasevich, Neil Horman, David S. Miller, linux-sctp, netdev,
LKML, syzkaller, Kostya Serebryany, Alexander Potapenko,
Sasha Levin, Eric Dumazet
On Wed, Dec 30, 2015 at 09:42:27PM +0100, Dmitry Vyukov wrote:
> Hello,
>
> The following program leads to a leak of two sock objects:
Damn, Dmitry ;-)
If no one takes care of it by then, I'll look into it next week, thanks.
Marcelo
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: net/sctp: sock memory leak
2015-12-30 20:42 net/sctp: sock memory leak Dmitry Vyukov
2015-12-30 20:47 ` Marcelo Ricardo Leitner
@ 2016-01-15 18:46 ` Marcelo Ricardo Leitner
2016-01-15 19:11 ` Dmitry Vyukov
1 sibling, 1 reply; 6+ messages in thread
From: Marcelo Ricardo Leitner @ 2016-01-15 18:46 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Vlad Yasevich, Neil Horman, David S. Miller, linux-sctp, netdev,
LKML, syzkaller, Kostya Serebryany, Alexander Potapenko,
Sasha Levin, Eric Dumazet
On Wed, Dec 30, 2015 at 09:42:27PM +0100, Dmitry Vyukov wrote:
> Hello,
>
> The following program leads to a leak of two sock objects:
...
>
> On commit 8513342170278468bac126640a5d2d12ffbff106 (Dec 28).
I'm afraid I cannot reproduce this one?
I enabled dynprintk at sctp_destroy_sock and it does print twice when I
run this test app.
Also added debugs to check association lifetime, and then it was
destroyed. Same for endpoint.
Checking with trace-cmd, both calls to sctp_close() resulted in
sctp_destroy_sock() being called.
As for sock_hold/put, they are matched too.
Ideas? Log is below for double checking
[ 1112.558217] sctp_endpoint_init(ffff88000015d400) sock_hold sk:ffff8800336da000
[ 1112.558539] sctp_endpoint_hold(ffff88000015d400)
[ 1112.558544] sctp_association_init(ffff8800b2db9000) sock_hold sk:ffff8800336da000
[ 1112.558878] sctp_association_hold(ffff8800b2db9000)
[ 1112.558957] sctp_association_hold(ffff8800b2db9000)
[ 1112.559062] sctp_association_hold(ffff8800b2db9000)
[ 1112.559079] sctp_association_hold(ffff8800b2db9000)
[ 1112.658745] sctp_endpoint_init(ffff88000015e200) sock_hold sk:ffff8800336dc800
[ 1112.658815] sctp_endpoint_put(ffff88000015d400)
[ 1112.658819] sctp_assoc_migrate(ffff8800b2db9000) sock_put sk:ffff8800336da000 oldsk:ffff8800336da000
[ 1112.658822] sctp_endpoint_hold(ffff88000015e200)
[ 1112.658824] sctp_assoc_migrate(ffff8800b2db9000) sock_hold sk:ffff8800336dc800
[ 1112.659627] sctp_association_put(ffff8800b2db9000)
[ 1112.659673] sctp_association_free(ffff8800b2db9000)
[ 1112.659691] sctp_association_put(ffff8800b2db9000)
[ 1112.659735] sctp_transport_put(ffff8800b3426000)
[ 1112.659737] sctp_transport_destroy(ffff8800b3426000)
[ 1112.659741] sctp_association_put(ffff8800b2db9000)
[ 1112.659745] sctp_association_put(ffff8800b2db9000)
[ 1112.659757] sctp_association_put(ffff8800b2db9000)
[ 1112.659759] sctp_association_destroy(ffff8800b2db9000)
[ 1112.659761] sctp_endpoint_put(ffff88000015e200)
[ 1112.659773] sctp_association_destroy(ffff8800b2db9000) sock_put sk:ffff8800336dc800
[ 1112.659814] sctp_close sock_hold sk:ffff8800336dc800
[ 1112.659818] sctp: sctp_destroy_sock: sk:ffff8800336dc800
[ 1112.659823] sctp_endpoint_put(ffff88000015e200)
[ 1112.659825] sctp_endpoint_destroy(ffff88000015e200)
[ 1112.659841] sctp_endpoint_destroy(ffff88000015e200) sock_put sk:ffff8800336dc800
[ 1112.659852] sctp_close sock_put sk:ffff8800336dc800
[ 1112.662437] sctp_close sock_hold sk:ffff8800336da000
[ 1112.662443] sctp: sctp_destroy_sock: sk:ffff8800336da000
[ 1112.662448] sctp_endpoint_put(ffff88000015d400)
[ 1112.662450] sctp_endpoint_destroy(ffff88000015d400)
[ 1112.662466] sctp_endpoint_destroy(ffff88000015d400) sock_put sk:ffff8800336da000
[ 1112.662476] sctp_close sock_put sk:ffff8800336da000
[ 1112.677226] sctp_transport_destroy_rcu(ffff8800b3426000)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: net/sctp: sock memory leak
2016-01-15 18:46 ` Marcelo Ricardo Leitner
@ 2016-01-15 19:11 ` Dmitry Vyukov
2016-03-02 8:56 ` Dmitry Vyukov
0 siblings, 1 reply; 6+ messages in thread
From: Dmitry Vyukov @ 2016-01-15 19:11 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: Vlad Yasevich, Neil Horman, David S. Miller, linux-sctp, netdev,
LKML, syzkaller, Kostya Serebryany, Alexander Potapenko,
Sasha Levin, Eric Dumazet
On Fri, Jan 15, 2016 at 7:46 PM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> On Wed, Dec 30, 2015 at 09:42:27PM +0100, Dmitry Vyukov wrote:
>> Hello,
>>
>> The following program leads to a leak of two sock objects:
> ...
>>
>> On commit 8513342170278468bac126640a5d2d12ffbff106 (Dec 28).
>
> I'm afraid I cannot reproduce this one?
> I enabled dynprintk at sctp_destroy_sock and it does print twice when I
> run this test app.
> Also added debugs to check association lifetime, and then it was
> destroyed. Same for endpoint.
>
> Checking with trace-cmd, both calls to sctp_close() resulted in
> sctp_destroy_sock() being called.
>
> As for sock_hold/put, they are matched too.
>
> Ideas? Log is below for double checking
Hummm... I can reproduce it pretty reliably.
[ 197.459024] kmemleak: 11 new suspected memory leaks (see
/sys/kernel/debug/kmemleak)
[ 307.494874] kmemleak: 409 new suspected memory leaks (see
/sys/kernel/debug/kmemleak)
[ 549.784022] kmemleak: 125 new suspected memory leaks (see
/sys/kernel/debug/kmemleak)
I double checked via /proc/slabinfo:
SCTPv6 4373 4420 2368 13 8 : tunables 0 0
0 : slabdata 340 340 0
SCTPv6 starts with almost 0, but grows infinitely while I run the
program in a loop.
Here is my SCTP related configs:
CONFIG_IP_SCTP=y
CONFIG_NET_SCTPPROBE=y
CONFIG_SCTP_DBG_OBJCNT=y
# CONFIG_SCTP_DEFAULT_COOKIE_HMAC_MD5 is not set
# CONFIG_SCTP_DEFAULT_COOKIE_HMAC_SHA1 is not set
CONFIG_SCTP_DEFAULT_COOKIE_HMAC_NONE=y
# CONFIG_SCTP_COOKIE_HMAC_MD5 is not set
# CONFIG_SCTP_COOKIE_HMAC_SHA1 is not set
I am on commit 67990608c8b95d2b8ccc29932376ae73d5818727 and I don't
seem to have any sctp-related changes on top.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: net/sctp: sock memory leak
2016-01-15 19:11 ` Dmitry Vyukov
@ 2016-03-02 8:56 ` Dmitry Vyukov
2016-03-02 19:42 ` Marcelo Ricardo Leitner
0 siblings, 1 reply; 6+ messages in thread
From: Dmitry Vyukov @ 2016-03-02 8:56 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: Vlad Yasevich, Neil Horman, David S. Miller, linux-sctp, netdev,
LKML, syzkaller, Kostya Serebryany, Alexander Potapenko,
Sasha Levin, Eric Dumazet
On Fri, Jan 15, 2016 at 8:11 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Fri, Jan 15, 2016 at 7:46 PM, Marcelo Ricardo Leitner
> <marcelo.leitner@gmail.com> wrote:
>> On Wed, Dec 30, 2015 at 09:42:27PM +0100, Dmitry Vyukov wrote:
>>> Hello,
>>>
>>> The following program leads to a leak of two sock objects:
>> ...
>>>
>>> On commit 8513342170278468bac126640a5d2d12ffbff106 (Dec 28).
>>
>> I'm afraid I cannot reproduce this one?
>> I enabled dynprintk at sctp_destroy_sock and it does print twice when I
>> run this test app.
>> Also added debugs to check association lifetime, and then it was
>> destroyed. Same for endpoint.
>>
>> Checking with trace-cmd, both calls to sctp_close() resulted in
>> sctp_destroy_sock() being called.
>>
>> As for sock_hold/put, they are matched too.
>>
>> Ideas? Log is below for double checking
>
>
> Hummm... I can reproduce it pretty reliably.
>
> [ 197.459024] kmemleak: 11 new suspected memory leaks (see
> /sys/kernel/debug/kmemleak)
> [ 307.494874] kmemleak: 409 new suspected memory leaks (see
> /sys/kernel/debug/kmemleak)
> [ 549.784022] kmemleak: 125 new suspected memory leaks (see
> /sys/kernel/debug/kmemleak)
>
> I double checked via /proc/slabinfo:
>
> SCTPv6 4373 4420 2368 13 8 : tunables 0 0
> 0 : slabdata 340 340 0
>
> SCTPv6 starts with almost 0, but grows infinitely while I run the
> program in a loop.
>
> Here is my SCTP related configs:
>
> CONFIG_IP_SCTP=y
> CONFIG_NET_SCTPPROBE=y
> CONFIG_SCTP_DBG_OBJCNT=y
> # CONFIG_SCTP_DEFAULT_COOKIE_HMAC_MD5 is not set
> # CONFIG_SCTP_DEFAULT_COOKIE_HMAC_SHA1 is not set
> CONFIG_SCTP_DEFAULT_COOKIE_HMAC_NONE=y
> # CONFIG_SCTP_COOKIE_HMAC_MD5 is not set
> # CONFIG_SCTP_COOKIE_HMAC_SHA1 is not set
>
> I am on commit 67990608c8b95d2b8ccc29932376ae73d5818727 and I don't
> seem to have any sctp-related changes on top.
Still happens on 4.5-rc6.
Marcelo, try to apply my config (if yours differs), run the program in
a parallel loop and check /proc/slabinfo (or kmemleak).
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: net/sctp: sock memory leak
2016-03-02 8:56 ` Dmitry Vyukov
@ 2016-03-02 19:42 ` Marcelo Ricardo Leitner
0 siblings, 0 replies; 6+ messages in thread
From: Marcelo Ricardo Leitner @ 2016-03-02 19:42 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Vlad Yasevich, Neil Horman, David S. Miller, linux-sctp, netdev,
LKML, syzkaller, Kostya Serebryany, Alexander Potapenko,
Sasha Levin, Eric Dumazet
On Wed, Mar 02, 2016 at 09:56:51AM +0100, Dmitry Vyukov wrote:
> On Fri, Jan 15, 2016 at 8:11 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
> > On Fri, Jan 15, 2016 at 7:46 PM, Marcelo Ricardo Leitner
> > <marcelo.leitner@gmail.com> wrote:
> >> On Wed, Dec 30, 2015 at 09:42:27PM +0100, Dmitry Vyukov wrote:
> >>> Hello,
> >>>
> >>> The following program leads to a leak of two sock objects:
> >> ...
> >>>
> >>> On commit 8513342170278468bac126640a5d2d12ffbff106 (Dec 28).
> >>
> >> I'm afraid I cannot reproduce this one?
> >> I enabled dynprintk at sctp_destroy_sock and it does print twice when I
> >> run this test app.
> >> Also added debugs to check association lifetime, and then it was
> >> destroyed. Same for endpoint.
> >>
> >> Checking with trace-cmd, both calls to sctp_close() resulted in
> >> sctp_destroy_sock() being called.
> >>
> >> As for sock_hold/put, they are matched too.
> >>
> >> Ideas? Log is below for double checking
> >
> >
> > Hummm... I can reproduce it pretty reliably.
> >
> > [ 197.459024] kmemleak: 11 new suspected memory leaks (see
> > /sys/kernel/debug/kmemleak)
> > [ 307.494874] kmemleak: 409 new suspected memory leaks (see
> > /sys/kernel/debug/kmemleak)
> > [ 549.784022] kmemleak: 125 new suspected memory leaks (see
> > /sys/kernel/debug/kmemleak)
> >
> > I double checked via /proc/slabinfo:
> >
> > SCTPv6 4373 4420 2368 13 8 : tunables 0 0
> > 0 : slabdata 340 340 0
> >
> > SCTPv6 starts with almost 0, but grows infinitely while I run the
> > program in a loop.
> >
> > Here is my SCTP related configs:
> >
> > CONFIG_IP_SCTP=y
> > CONFIG_NET_SCTPPROBE=y
> > CONFIG_SCTP_DBG_OBJCNT=y
> > # CONFIG_SCTP_DEFAULT_COOKIE_HMAC_MD5 is not set
> > # CONFIG_SCTP_DEFAULT_COOKIE_HMAC_SHA1 is not set
> > CONFIG_SCTP_DEFAULT_COOKIE_HMAC_NONE=y
> > # CONFIG_SCTP_COOKIE_HMAC_MD5 is not set
> > # CONFIG_SCTP_COOKIE_HMAC_SHA1 is not set
> >
> > I am on commit 67990608c8b95d2b8ccc29932376ae73d5818727 and I don't
> > seem to have any sctp-related changes on top.
>
>
> Still happens on 4.5-rc6.
>
> Marcelo, try to apply my config (if yours differs), run the program in
> a parallel loop and check /proc/slabinfo (or kmemleak).
Hi Dmitry, I'm just back from PTOs. Will get back to this asap.
Thanks,
Marcelo
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-03-02 19:42 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-12-30 20:42 net/sctp: sock memory leak Dmitry Vyukov
2015-12-30 20:47 ` Marcelo Ricardo Leitner
2016-01-15 18:46 ` Marcelo Ricardo Leitner
2016-01-15 19:11 ` Dmitry Vyukov
2016-03-02 8:56 ` Dmitry Vyukov
2016-03-02 19:42 ` Marcelo Ricardo Leitner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox