linux-kernel - Re: net/sctp: use-after-free in __sctp

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]

Date:	Tue, 19 Jan 2016 09:38:54 -0500
From:	Vlad Yasevich <vyasevich@...il.com>
To:	Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
	Dmitry Vyukov <dvyukov@...gle.com>
Cc:	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>,
	Eric Dumazet <edumazet@...gle.com>,
	syzkaller <syzkaller@...glegroups.com>,
	Kostya Serebryany <kcc@...gle.com>,
	Alexander Potapenko <glider@...gle.com>,
	Sasha Levin <sasha.levin@...cle.com>
Subject: Re: net/sctp: use-after-free in __sctp_connect

On 01/15/2016 02:01 PM, Marcelo Ricardo Leitner wrote:
> On Wed, Jan 13, 2016 at 10:52:31AM +0100, Dmitry Vyukov wrote:
>> Hello,
>>
>> The following program causes use-after-free in __sctp_connect:
>>
> ...
>> INFO: Freed in sctp_association_put+0x150/0x250 age=0 cpu=3 pid=15267
>> [<      none      >] __slab_free+0x1fc/0x320 mm/slub.c:2678
>> [<     inline     >] slab_free mm/slub.c:2833
>> [<      none      >] kfree+0x2a8/0x2d0 mm/slub.c:3662
>> [<     inline     >] sctp_association_destroy net/sctp/associola.c:424
>> [<      none      >] sctp_association_put+0x150/0x250 net/sctp/associola.c:860
>> [<      none      >] sctp_wait_for_connect+0x37c/0x4f0 net/sctp/socket.c:7067
>                          ^^^^^^^^^^^^^^
>> [<      none      >] __sctp_connect+0x905/0xb90 net/sctp/socket.c:1215
>> [<      none      >] __sctp_setsockopt_connectx+0x198/0x1d0
>> net/sctp/socket.c:1328
>> [<     inline     >] sctp_setsockopt_connectx net/sctp/socket.c:1360
>> [<      none      >] sctp_setsockopt+0x226/0x3630 net/sctp/socket.c:3728
>> [<      none      >] sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2642
>> [<     inline     >] SYSC_setsockopt net/socket.c:1752
>> [<      none      >] SyS_setsockopt+0x158/0x240 net/socket.c:1731
>> [<      none      >] entry_SYSCALL_64_fastpath+0x16/0x7a
>> arch/x86/entry/entry_64.S:185
> 
> This one may sher some light on that other socket leak one, because the
> association shouldn't have been freed at that point.
> Now, how it managed to unbalance that refcnt, hmm...
> 

The free may be a result of implicit close when the program ends.  If the thread
is still waiting for connect to finish when the program ends, we may end up
in a situation when the association has been freed, but the ref held by wait_for_connect
prevents the destruction.  When wait_for_connect finishes in puts the ref and
causes the destruction.

What I am guessing is happing is the wait_for_connect doesn't catch the error condition
correctly and thus __sctp_connect() doesn't think there was and error and references
the assoc which was just destroyed.

-vlad