netdev - Re: net/sctp: sock memory leak

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACT4Y+ar4nQyTtUpWZU4YEGdmLiJ1F5QDS=80YmTuuUNG4MNpg@mail.gmail.com>
Date:	Wed, 2 Mar 2016 09:56:51 +0100
From:	Dmitry Vyukov <dvyukov@...gle.com>
To:	Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
Cc:	Vlad Yasevich <vyasevich@...il.com>,
	Neil Horman <nhorman@...driver.com>,
	"David S. Miller" <davem@...emloft.net>,
	linux-sctp@...r.kernel.org, netdev <netdev@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	syzkaller <syzkaller@...glegroups.com>,
	Kostya Serebryany <kcc@...gle.com>,
	Alexander Potapenko <glider@...gle.com>,
	Sasha Levin <sasha.levin@...cle.com>,
	Eric Dumazet <edumazet@...gle.com>
Subject: Re: net/sctp: sock memory leak

On Fri, Jan 15, 2016 at 8:11 PM, Dmitry Vyukov <dvyukov@...gle.com> wrote:
> On Fri, Jan 15, 2016 at 7:46 PM, Marcelo Ricardo Leitner
> <marcelo.leitner@...il.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).