From patchwork Tue Oct 17 15:26:10 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Xin Long X-Patchwork-Id: 827077 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="sO88xzUH"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3yGfDJ0MZWz9t16 for ; Wed, 18 Oct 2017 02:26:24 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759005AbdJQP0V (ORCPT ); Tue, 17 Oct 2017 11:26:21 -0400 Received: from mail-pf0-f193.google.com ([209.85.192.193]:44336 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754455AbdJQP0T (ORCPT ); Tue, 17 Oct 2017 11:26:19 -0400 Received: by mail-pf0-f193.google.com with SMTP id x7so1596239pfa.1; Tue, 17 Oct 2017 08:26:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=A9SLQ+03bgyhvL5dR94pPdxhskxMqdDCuwusIKaFNoM=; b=sO88xzUHOtAR/P1LIaG8Rv6yTpXQc9H3Km4TJZ/o++rQpedkD6lKVwCJMXeaqeOj6i V9va6mRwdR5KGVimiQxZSVhgUm7Mmhr/heidgO6g8in1ILaMGpKpZyVpbuObFyhbw2A2 yARWgKK6Y1CP+uOd9jXZRNCVZRVpp65wXt5TOkHS0aOVRm71Fll77sphz6PRCZm5zHsE aSjmibqDGyHst8ejVl7TteARcNhHBku9gLMKzOLXq/iWGYinJLmSc+8RTTGr15Kfjk7e 8vVowEEKL4Tx5ZDgnNRHTr+LBVy0mIR62/tuTNj4xGAMeqCx/Cx7+b82Zdayh2nM49YX Kbgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=A9SLQ+03bgyhvL5dR94pPdxhskxMqdDCuwusIKaFNoM=; b=lwAEauprH5GMePAxu6Ajf7n77GpK+h3q+KcC9L4xWL8+7gbXDR8+msuT/1bvFfzgdz tSUaGwmX7uN65KAUHVZ4ErHdNEh1LCwchxME68Y4i1gABtfNcn7nLsOU8XVX6cEY15Gb NyjEioec7DO1q1Fx/Xv7W26qoy73uh2jDXERB92bSyWYTg7v6pMwLkjMtShS8b+NEAxH EweVQORA+9Hvtk0cD3hstXxoFZTFUafRKSd216ZhBTp1AHl7cHUpQjhLTGWANbl9ntNV hVaYpnadeVH7YyVQ4CFTrGipgJ6k4Ri4Q8Z684U/4C1iVsEYf0tAy5NfhhVdEu/RoqBN vN8w== X-Gm-Message-State: AMCzsaUDxZD3OfTdQfTYbmR73I6E8QYY3uDzhBIvITCJBdvgbY/9uzM5 odKdZ+nh9CdHMf5y92z/DO1lYf4e X-Google-Smtp-Source: AOwi7QD6rRfauQuImNVpCw6kcRIJy3X48aBGC+5pHzIdkgHzgAPAcwAT5oHdhGkdh/p2uKLU4ozD2Q== X-Received: by 10.99.95.201 with SMTP id t192mr9581307pgb.398.1508253978429; Tue, 17 Oct 2017 08:26:18 -0700 (PDT) Received: from localhost ([209.132.188.80]) by smtp.gmail.com with ESMTPSA id d8sm11816242pfh.13.2017.10.17.08.26.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Oct 2017 08:26:17 -0700 (PDT) From: Xin Long To: network dev , linux-sctp@vger.kernel.org Cc: davem@davemloft.net, Marcelo Ricardo Leitner , Neil Horman , chunwang@redhat.com, syzkaller@googlegroups.com Subject: [PATCH net] sctp: do not peel off an assoc from one netns to another one Date: Tue, 17 Oct 2017 23:26:10 +0800 Message-Id: X-Mailer: git-send-email 2.1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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: socket$inet6_sctp() bind$inet6() sendto$inet6() unshare(0x40000000) getsockopt$inet_sctp6_SCTP_GET_ASSOC_ID_LIST() getsockopt$inet_sctp6_SCTP_SOCKOPT_PEELOFF() 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 different. Reported-by: ChunYu Wang Signed-off-by: Xin Long Acked-by: Marcelo Ricardo Leitner Acked-by: Neil Horman --- net/sctp/socket.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/net/sctp/socket.c b/net/sctp/socket.c index d4730ad..17841ab 100644 --- a/net/sctp/socket.c +++ b/net/sctp/socket.c @@ -4906,6 +4906,10 @@ int sctp_do_peeloff(struct sock *sk, sctp_assoc_t id, struct socket **sockp) 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;