linux-kernel - 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: <20160115184620.GE6074@mrl.redhat.com>
Date:	Fri, 15 Jan 2016 16:46:20 -0200
From:	Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
To:	Dmitry Vyukov <dvyukov@...gle.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 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)