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: <20160115190106.GG6074@mrl.redhat.com>
Date:	Fri, 15 Jan 2016 17:01:06 -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>,
	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 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...

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ