From patchwork Thu Dec 7 15:07:00 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kleber Sacilotto de Souza X-Patchwork-Id: 845633 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) by ozlabs.org (Postfix) with ESMTP id 3yszNh4Ngtz9t3R; Fri, 8 Dec 2017 02:07:16 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1eMxlW-0005kQ-B9; Thu, 07 Dec 2017 15:07:10 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.86_2) (envelope-from ) id 1eMxlU-0005jN-Kl for kernel-team@lists.ubuntu.com; Thu, 07 Dec 2017 15:07:08 +0000 Received: from mail-wr0-f200.google.com ([209.85.128.200]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1eMxlU-00038E-DT for kernel-team@lists.ubuntu.com; Thu, 07 Dec 2017 15:07:08 +0000 Received: by mail-wr0-f200.google.com with SMTP id t92so4243364wrc.13 for ; Thu, 07 Dec 2017 07:07:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references; bh=tbabKRh2WrE0UcO/MrNR9ae2Usz6MjZ7vSEgWIqJA5o=; b=M0oG+NU6KvcXFZB8Kd0IVAueq3SUTiqNKBFGfrqS+X//5nIDX1dbgREyq6Cuwg2Sr3 kaUH5r6GXtOlt8HVIyiTVUrAzzja6NQO4HUH3qvPj2Bh8cTmf6ZPW7RKHYXcqj6LWoBb EKaaAdlQnLoVFYQfvqKs1BuQseeSyKCHmwx2Z3SmKk4A+X2+iORoaLH2zDEs2xAoRYxl z6C66FMGCMe2c14TkYARK1MtUTYkYK50Q616gMFoqnuDnv4OAgIqdO6tNWZF13mdOtzN 77Nk2yP4RQ9rBuA2ClSoTOWCkUrMki3a6Vs+4x8DniApAtAxDVqDv23rsySDC6DF7610 ZJKw== X-Gm-Message-State: AJaThX7wGCxaUBouuK+CwrWiaee1zn6XKKFSe0eWOeyUilpc80J4ocLs 1uMZSqiXWKqwZmzsw/G0FKDbKq9aBrUOAvw7tZG54mG5gCdbZmYtFnKR09T9zlYBhJNQJPDgb6p vc+3von0uDb/bjFVwmxj0tVquNlNo6mHk5De/4Ul83A== X-Received: by 10.223.142.49 with SMTP id n46mr23121424wrb.279.1512659227783; Thu, 07 Dec 2017 07:07:07 -0800 (PST) X-Google-Smtp-Source: AGs4zMaoN1/v5HZljLHHhvGngrWEFdjT0NJgmZ4d2rTFRxv1Dj5ehftR9mXygC7L9Aoh8eb66Vv4ag== X-Received: by 10.223.142.49 with SMTP id n46mr23121408wrb.279.1512659227555; Thu, 07 Dec 2017 07:07:07 -0800 (PST) Received: from localhost ([2a02:8109:98c0:1604:b972:f7ea:7fbe:5583]) by smtp.gmail.com with ESMTPSA id i8sm5792986wmh.42.2017.12.07.07.07.06 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 07 Dec 2017 07:07:06 -0800 (PST) From: Kleber Sacilotto de Souza To: kernel-team@lists.ubuntu.com Subject: [SRU][Xenial][Zesty][Artful][PATCH 1/1] sctp: do not peel off an assoc from one netns to another one Date: Thu, 7 Dec 2017 16:07:00 +0100 Message-Id: <20171207150700.12824-3-kleber.souza@canonical.com> X-Mailer: git-send-email 2.14.1 In-Reply-To: <20171207150700.12824-1-kleber.souza@canonical.com> References: <20171207150700.12824-1-kleber.souza@canonical.com> X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Xin Long 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 Signed-off-by: David S. Miller CVE-2017-15115 (cherry picked from commit df80cd9b28b9ebaa284a41df611dbf3a2d05ca74) Signed-off-by: Kleber Sacilotto de Souza Acked-by: Colin Ian King --- net/sctp/socket.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/net/sctp/socket.c b/net/sctp/socket.c index d4730ada7f32..17841ab30798 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;