From patchwork Thu Apr 20 12:32:57 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Salvatore Bonaccorso X-Patchwork-Id: 752785 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3w7yvZ44Ygz9s7g for ; Thu, 20 Apr 2017 22:33:14 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="L7YTJPXO"; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S945329AbdDTMdN (ORCPT ); Thu, 20 Apr 2017 08:33:13 -0400 Received: from mail-yw0-f196.google.com ([209.85.161.196]:35460 "EHLO mail-yw0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S945325AbdDTMdK (ORCPT ); Thu, 20 Apr 2017 08:33:10 -0400 Received: by mail-yw0-f196.google.com with SMTP id k13so5920423ywk.2 for ; Thu, 20 Apr 2017 05:33:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=L7Dnj7/lysCO0A6ABFaQ5HeTeS53ai60zUnWMObT1mQ=; b=L7YTJPXOdmLoytJXKM8cGSNzk1ctWhz5qzyPNy67QYvhMaMvTF1qyuzKF1Y9GAo0tR UoPbVE63rpALE8b4bNrkWHx7CEtJtLZGu2EhdJIcECqTQkYgE1oodKe6CWQs4Wu4SNm2 UIc58R5fo7BPW5YdPHb06an7KG4lSFkMBGYmt19RiMMi8sEwVw0hCU6WDOtAwgVNbOrI zka+Kx9rOj8as+/MEkbBfBH58Mtd/hRUI2bN+RhncOPEUN4N+TMbwbAtNh1kqMeKiSjV I+zQ0R/HAKCnBqq1a2WKoX+flSFDPjprjQNEoWlLd3TbxAXX7FJqK8+qw1Y9x03Uh5Q+ B8XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=L7Dnj7/lysCO0A6ABFaQ5HeTeS53ai60zUnWMObT1mQ=; b=CqT7F2dGU0rQpyZptpm54zKk6+JJDBZrvzHlaeMFI7OCQur+du5Kx+9mQUYH3ZVn4G nCpduDhT128VV+oy80+eG/lmjeOTV9TASFgduX+8UxEUDkXQpquYxBtgDmeMc4IVrVR2 jjPw7KH8gwwmAABAdbO5nOdumNx5W29EiGyW5nkuemThzKLUpOHXYOxsHTCQMCPFRfSX vzoIOIsrt8vip1KdkvgNf+0r2WlPps2LshtaogEFCFRQMOP1AFGkOK7gWouXDZkYg0vw GcsXshC9szC6dlW69kex0irklYRKw6baZkXHBhcfG+uqsLKf9V+pj8dpfqhJDl+B0JPS cg5g== X-Gm-Message-State: AN3rC/5UNJodBFT4EbWLhCeZFlK+WbVJICSgtOoIGX/MID0Ea9osFOMa /nbWuXpMAVh4cA== X-Received: by 10.129.128.194 with SMTP id q185mr6206934ywf.143.1492691579956; Thu, 20 Apr 2017 05:32:59 -0700 (PDT) Received: from lorien (lorien.valinor.li. [2a01:4f8:192:61d5::2]) by smtp.gmail.com with ESMTPSA id m28sm221522ywh.55.2017.04.20.05.32.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Apr 2017 05:32:59 -0700 (PDT) Date: Thu, 20 Apr 2017 14:32:57 +0200 From: Salvatore Bonaccorso To: netdev@vger.kernel.org Cc: Alexander Popov , Ben Hutchings , Marcelo Ricardo Leitner , Xin Long , "David S. Miller" Subject: Re: sctp: deny peeloff operation on asocs with threads sleeping on it Message-ID: <20170420123257.GA11798@lorien.valinor.li> References: <20170420114405.mh7r5otmvpksacqd@lorien.valinor.li> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20170420114405.mh7r5otmvpksacqd@lorien.valinor.li> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hi According to the documentation I should have sent this to netdev@vger.kernel.org rather than stable@vger.kernel.org. Rationale: Whilst 00eff2ebbd229758e90659907724c14dd5a18339 went to stable, the dfcb9f4f99f1e9a49e43398a7bfbf56927544af1 commit is missing. Full quoting, my original misleaded mail: On Thu, Apr 20, 2017 at 01:44:05PM +0200, Salvatore Bonaccorso wrote: > Hi > > Apparently the following commit > > dfcb9f4f99f1e9a49e43398a7bfbf56927544af1 (sctp: deny peeloff operation > on asocs with threads sleeping on it) > > (was not CC'ed stable@vger.kernel.org, but was already applied in > 3.2.87 and 3.16.42) is missing from 4.9: > > 2dcab598484185dea7ec22219c76dcdd59e3cb90 was included in 4.9.11 via > 00eff2ebbd229758e90659907724c14dd5a18339 . But > dfcb9f4f99f1e9a49e43398a7bfbf56927544af1 is missing from 4.9. > > This was assigned CVE-2017-6353. > > Reference: > https://marc.info/?l=linux-netdev&m=148785309416337&w=2 > http://www.openwall.com/lists/oss-security/2017/02/27/2 > > Regards, > Salvatore Regards, Salvatore From dfcb9f4f99f1e9a49e43398a7bfbf56927544af1 Mon Sep 17 00:00:00 2001 From: Marcelo Ricardo Leitner Date: Thu, 23 Feb 2017 09:31:18 -0300 Subject: [PATCH] sctp: deny peeloff operation on asocs with threads sleeping on it 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 Cc: Ben Hutchings Signed-off-by: Marcelo Ricardo Leitner Signed-off-by: Xin Long Signed-off-by: David S. Miller --- net/sctp/socket.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/net/sctp/socket.c b/net/sctp/socket.c index b532148..465a9c8 100644 --- a/net/sctp/socket.c +++ b/net/sctp/socket.c @@ -4862,6 +4862,12 @@ int sctp_do_peeloff(struct sock *sk, sctp_assoc_t id, struct socket **sockp) 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. */ @@ -7599,8 +7605,6 @@ static int sctp_wait_for_sndbuf(struct sctp_association *asoc, long *timeo_p, */ release_sock(sk); current_timeo = schedule_timeout(current_timeo); - if (sk != asoc->base.sk) - goto do_error; lock_sock(sk); *timeo_p = current_timeo; -- 2.1.4