rpms
/
kernel
2
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

CVE-2017-6353 Possible double free in stcp_sendmsg (rhbz 1428907 1428910)

This commit is contained in:
Justin M. Forbes 2017-03-06 09:49:12 -06:00
parent b83da9ac2e
commit 58bba40da4
2 changed files with 72 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
kernel.spec
View File

@ -651,6 +651,9 @@ Patch862: rt2800-warning.patch
#CVE-2017-5669 rhbz 1427239
Patch863: ipc-shm-Fix-shmat-mmap-nil-page-protection.patch
#CVE-2017-6353 rhbz 1428907 1428910
Patch864: sctp-deny-peeloff-operation-on-asocs-with-threads-sl.patch
# END OF PATCH DEFINITIONS
%endif
@ -2197,6 +2200,9 @@ fi
#
#
%changelog
* Mon Mar 6 2017 Justin M. Forbes <jforbes@fedoraproject.org>
- CVE-2017-6353 Possible double free in stcp_sendmsg (rhbz 1428907 1428910)
* Wed Mar 1 2017 Peter Robinson <pbrobinson@fedoraproject.org>
- Add patch to fix desktop lockups on RPi (vc4) RHBZ# 1389163

66
sctp-deny-peeloff-operation-on-asocs-with-threads-sl.patch Normal file
View File

@ -0,0 +1,66 @@
From dfcb9f4f99f1e9a49e43398a7bfbf56927544af1 Mon Sep 17 00:00:00 2001
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date: Thu, 23 Feb 2017 09:31:18 -0300
Subject: [PATCH] sctp: deny peeloff operation on asocs with threads sleeping
on it
commit 2dcab5984841 ("sctp: avoid BUG_ON on sctp_wait_for_sndbuf")
attempted to avoid a BUG_ON call when the association being used for a
sendmsg() is blocked waiting for more sndbuf and another thread did a
peeloff operation on such asoc, moving it to another socket.
As Ben Hutchings noticed, then in such case it would return without
locking back the socket and would cause two unlocks in a row.
Further analysis also revealed that it could allow a double free if the
application managed to peeloff the asoc that is created during the
sendmsg call, because then sctp_sendmsg() would try to free the asoc
that was created only for that call.
This patch takes another approach. It will deny the peeloff operation
if there is a thread sleeping on the asoc, so this situation doesn't
exist anymore. This avoids the issues described above and also honors
the syscalls that are already being handled (it can be multiple sendmsg
calls).
Joint work with Xin Long.
Fixes: 2dcab5984841 ("sctp: avoid BUG_ON on sctp_wait_for_sndbuf")
Cc: Alexander Popov <alex.popov@linux.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/sctp/socket.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index b532148..465a9c8 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -4862,6 +4862,12 @@ int sctp_do_peeloff(struct sock *sk, sctp_assoc_t id, struct socket **sockp)
if (!asoc)
return -EINVAL;
+ /* If there is a thread waiting on more sndbuf space for
+ * sending on this asoc, it cannot be peeled.
+ */
+ if (waitqueue_active(&asoc->wait))
+ return -EBUSY;
+
/* An association cannot be branched off from an already peeled-off
* socket, nor is this supported for tcp style sockets.
*/
@@ -7599,8 +7605,6 @@ static int sctp_wait_for_sndbuf(struct sctp_association *asoc, long *timeo_p,
*/
release_sock(sk);
current_timeo = schedule_timeout(current_timeo);
- if (sk != asoc->base.sk)
- goto do_error;
lock_sock(sk);
*timeo_p = current_timeo;
--
2.9.3