sctp: deny peeloff operation on asocs with threads sleeping on it (CVE-2017-6353)
This commit is contained in:
parent
28bcf3a477
commit
49569a3b8c
|
@ -94,6 +94,8 @@ linux (4.9.13-1) UNRELEASED; urgency=medium
|
|||
* [x86] kvm: fix page struct leak in handle_vmon (CVE-2017-2596)
|
||||
* ipc/shm: Fix shmat mmap nil-page protection (CVE-2017-5669)
|
||||
* time: Disable TIMER_STATS (CVE-2017-5967)
|
||||
* sctp: deny peeloff operation on asocs with threads sleeping on it
|
||||
(CVE-2017-6353)
|
||||
|
||||
-- Ben Hutchings <ben@decadent.org.uk> Sat, 18 Feb 2017 00:38:10 +0000
|
||||
|
||||
|
|
61
debian/patches/bugfix/all/sctp-deny-peeloff-operation-on-asocs-with-threads-sl.patch
vendored
Normal file
61
debian/patches/bugfix/all/sctp-deny-peeloff-operation-on-asocs-with-threads-sl.patch
vendored
Normal file
|
@ -0,0 +1,61 @@
|
|||
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
|
||||
Date: Thu, 23 Feb 2017 09:31:18 -0300
|
||||
Subject: sctp: deny peeloff operation on asocs with threads sleeping on it
|
||||
Origin: https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit?id=dfcb9f4f99f1e9a49e43398a7bfbf56927544af1
|
||||
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2017-6353
|
||||
|
||||
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(-)
|
||||
|
||||
--- a/net/sctp/socket.c
|
||||
+++ b/net/sctp/socket.c
|
||||
@@ -4735,6 +4735,12 @@ int sctp_do_peeloff(struct sock *sk, sct
|
||||
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.
|
||||
*/
|
||||
@@ -7427,8 +7433,6 @@ static int sctp_wait_for_sndbuf(struct s
|
||||
*/
|
||||
release_sock(sk);
|
||||
current_timeo = schedule_timeout(current_timeo);
|
||||
- if (sk != asoc->base.sk)
|
||||
- goto do_error;
|
||||
lock_sock(sk);
|
||||
|
||||
*timeo_p = current_timeo;
|
|
@ -111,6 +111,7 @@ debian/i386-686-pae-pci-set-pci-nobios-by-default.patch
|
|||
bugfix/x86/kvm-fix-page-struct-leak-in-handle_vmon.patch
|
||||
bugfix/all/ipc-shm-fix-shmat-mmap-nil-page-protection.patch
|
||||
debian/time-mark-timer_stats-as-broken.patch
|
||||
bugfix/all/sctp-deny-peeloff-operation-on-asocs-with-threads-sl.patch
|
||||
|
||||
# Fix exported symbol versions
|
||||
bugfix/ia64/revert-ia64-move-exports-to-definitions.patch
|
||||
|
|
Loading…
Reference in New Issue