LKML Archive on
help / color / mirror / Atom feed
From: Greg Kroah-Hartman <>
Cc: Greg Kroah-Hartman <>,, ChunYu Wang <>,
	Xin Long <>,
	Marcelo Ricardo Leitner <>,
	Neil Horman <>,
	"David S. Miller" <>
Subject: [PATCH 3.18 05/12] sctp: do not peel off an assoc from one netns to another one
Date: Wed, 22 Nov 2017 11:11:48 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

3.18-stable review patch.  If anyone has any objections, please let me know.


From: Xin Long <>

[ Upstream commit df80cd9b28b9ebaa284a41df611dbf3a2d05ca74 ]

Now when peeling off an association to the sock in another netns, all
transports in this assoc are not to be rehashed and keep use the old
key in hashtable.

As a transport uses sk->net as the hash key to insert into hashtable,
it would miss removing these transports from hashtable due to the new
netns when closing the sock and all transports are being freeed, then
later an use-after-free issue could be caused when looking up an asoc
and dereferencing those transports.

This is a very old issue since very beginning, ChunYu found it with
syzkaller fuzz testing with this series:


This patch is to block this call when peeling one assoc off from one
netns to another one, so that the netns of all transport would not
go out-sync with the key in hashtable.

Note that this patch didn't fix it by rehashing transports, as it's
difficult to handle the situation when the tuple is already in use
in the new netns. Besides, no one would like to peel off one assoc
to another netns, considering ipaddrs, ifaces, etc. are usually

Reported-by: ChunYu Wang <>
Signed-off-by: Xin Long <>
Acked-by: Marcelo Ricardo Leitner <>
Acked-by: Neil Horman <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
 net/sctp/socket.c |    4 ++++
 1 file changed, 4 insertions(+)

--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -4466,6 +4466,10 @@ int sctp_do_peeloff(struct sock *sk, sct
 	struct socket *sock;
 	int err = 0;
+	/* Do not peel off from one netns to another one. */
+	if (!net_eq(current->nsproxy->net_ns, sock_net(sk)))
+		return -EINVAL;
 	if (!asoc)
 		return -EINVAL;

  parent reply	other threads:[~2017-11-22 10:12 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-22 10:11 [PATCH 3.18 00/12] 3.18.84-stable review Greg Kroah-Hartman
2017-11-22 10:11 ` [PATCH 3.18 01/12] ipv6/dccp: do not inherit ipv6_mc_list from parent Greg Kroah-Hartman
2017-11-22 10:11 ` [PATCH 3.18 02/12] net/sctp: Always set scope_id in sctp_inet6_skb_msgname Greg Kroah-Hartman
2017-11-22 10:11 ` [PATCH 3.18 03/12] tcp: do not mangle skb->cb[] in tcp_make_synack() Greg Kroah-Hartman
2017-11-22 10:11 ` [PATCH 3.18 04/12] netfilter/ipvs: clear ipvs_property flag when SKB net namespace changed Greg Kroah-Hartman
2017-11-22 10:11 ` Greg Kroah-Hartman [this message]
2017-11-22 10:11 ` [PATCH 3.18 06/12] fealnx: Fix building error on MIPS Greg Kroah-Hartman
2017-11-22 10:11 ` [PATCH 3.18 07/12] af_netlink: ensure that NLMSG_DONE never fails in dumps Greg Kroah-Hartman
2017-11-22 10:11 ` [PATCH 3.18 08/12] vlan: fix a use-after-free in vlan_device_event() Greg Kroah-Hartman
2017-11-22 10:11 ` [PATCH 3.18 09/12] ima: do not update security.ima if appraisal status is not INTEGRITY_PASS Greg Kroah-Hartman
2017-11-22 10:11 ` [PATCH 3.18 10/12] ocfs2: should wait dio before inode lock in ocfs2_setattr() Greg Kroah-Hartman
2017-11-22 10:11 ` [PATCH 3.18 11/12] ipmi: fix unsigned long underflow Greg Kroah-Hartman
2017-11-22 10:11 ` [PATCH 3.18 12/12] coda: fix kernel memory exposure attempt in fsync Greg Kroah-Hartman
     [not found] ` <>
2017-11-22 14:57   ` [PATCH 3.18 00/12] 3.18.84-stable review Greg Kroah-Hartman
     [not found]   ` <>
2017-11-23  7:29     ` Greg Kroah-Hartman
2017-11-22 21:32 ` Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).