Skip to contentSkip to conversation

Patch "sctp: deny peeloff operation on asocs with threads sleeping on it" has been added to the 4.10-stable tree

PATCH [email protected] 1 participant 1 message Mar 18, 2017

Subsystems (3)
lore
Share & tools
lore

[email protected]

author maintainer Applied
#0 lore raw

This is a note to let you know that I've just added the patch titled

sctp: deny peeloff operation on asocs with threads sleeping on it

to the 4.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
sctp-deny-peeloff-operation-on-asocs-with-threads-sleeping-on-it.patch
and it can be found in the queue-4.10 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

Quoted 1 line

From foo@baz Sat Mar 18 22:03:53 CST 2017

From: Marcelo Ricardo Leitner <[email protected]>
Date: Thu, 23 Feb 2017 09:31:18 -0300
Subject: sctp: deny peeloff operation on asocs with threads sleeping on it

From: Marcelo Ricardo Leitner <[email protected]>

[ Upstream commit dfcb9f4f99f1e9a49e43398a7bfbf56927544af1 ]

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 <[email protected]>
Cc Ben Hutchings <[email protected]>
---
 net/sctp/socket.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
net/sctp/socket.c +6 -2
@@ -4734,6 +4734,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.
 	 */
@@ -7426,8 +7432,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;

Patches currently in stable-queue which might be from [email protected] are

queue-4.10/sctp-deny-peeloff-operation-on-asocs-with-threads-sleeping-on-it.patch