linux-kernel - [PATCH 3.16 337/370] sctp: assign assoc_id earlier 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]

Message-ID: <lsq.1489146383.138241521@decadent.org.uk>
Date:   Fri, 10 Mar 2017 11:46:23 +0000
From:   Ben Hutchings <ben@...adent.org.uk>
To:     linux-kernel@...r.kernel.org, stable@...r.kernel.org
CC:     akpm@...ux-foundation.org,
        "Andrey Konovalov" <andreyknvl@...gle.com>,
        "Marcelo Ricardo Leitner" <marcelo.leitner@...il.com>,
        "Neil Horman" <nhorman@...driver.com>,
        "Dmitry Vyukov" <dvyukov@...gle.com>,
        "Xin Long" <lucien.xin@...il.com>,
        "David S. Miller" <davem@...emloft.net>
Subject: [PATCH 3.16 337/370] sctp: assign assoc_id earlier in __sctp_connect

3.16.42-rc1 review patch.  If anyone has any objections, please let me know.

------------------

From: Marcelo Ricardo Leitner <marcelo.leitner@...il.com>

[ Upstream commit 7233bc84a3aeda835d334499dc00448373caf5c0 ]

sctp_wait_for_connect() currently already holds the asoc to keep it
alive during the sleep, in case another thread release it. But Andrey
Konovalov and Dmitry Vyukov reported an use-after-free in such
situation.

Problem is that __sctp_connect() doesn't get a ref on the asoc and will
do a read on the asoc after calling sctp_wait_for_connect(), but by then
another thread may have closed it and the _put on sctp_wait_for_connect
will actually release it, causing the use-after-free.

Fix is, instead of doing the read after waiting for the connect, do it
before so, and avoid this issue as the socket is still locked by then.
There should be no issue on returning the asoc id in case of failure as
the application shouldn't trust on that number in such situations
anyway.

This issue doesn't exist in sctp_sendmsg() path.

Reported-by: Dmitry Vyukov <dvyukov@...gle.com>
Reported-by: Andrey Konovalov <andreyknvl@...gle.com>
Tested-by: Andrey Konovalov <andreyknvl@...gle.com>
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
Reviewed-by: Xin Long <lucien.xin@...il.com>
Acked-by: Neil Horman <nhorman@...driver.com>
Signed-off-by: David S. Miller <davem@...emloft.net>
Signed-off-by: Ben Hutchings <ben@...adent.org.uk>
---
 net/sctp/socket.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -1217,9 +1217,12 @@ static int __sctp_connect(struct sock *s

 	timeo = sock_sndtimeo(sk, f_flags & O_NONBLOCK);

-	err = sctp_wait_for_connect(asoc, &timeo);
-	if ((err == 0 || err == -EINPROGRESS) && assoc_id)
+	if (assoc_id)
 		*assoc_id = asoc->assoc_id;
+	err = sctp_wait_for_connect(asoc, &timeo);
+	/* Note: the asoc may be freed after the return of
+	 * sctp_wait_for_connect.
+	 */

 	/* Don't free association on exit. */
 	asoc = NULL;