From patchwork Thu Feb 23 12:31:18 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marcelo Ricardo Leitner X-Patchwork-Id: 731526 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 3vTYWW4QPcz9s7N for ; Thu, 23 Feb 2017 23:31:35 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="nBgCTGjJ"; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751156AbdBWMbb (ORCPT ); Thu, 23 Feb 2017 07:31:31 -0500 Received: from mail-qk0-f195.google.com ([209.85.220.195]:36711 "EHLO mail-qk0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751070AbdBWMba (ORCPT ); Thu, 23 Feb 2017 07:31:30 -0500 Received: by mail-qk0-f195.google.com with SMTP id r90so4444709qki.3; Thu, 23 Feb 2017 04:31:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=YFNA4ELam5YRUPxAgIQjtApdkuuJ6lQE0Iae69YHCAM=; b=nBgCTGjJYfq5CDUKqJY6bO5pkSwcKZp4qoFDJRa5YKQCoHVo9Y6zR4Do+cdKAgewxb D+FRzNeC2/qwGj8uYqoIPhN36UnBvtztveDwv697cTLfe5RTTZSopZrYfkh0ewFyOHxe bEuJLW+A0IU2SgBybC54ly0t2SACkQQ3VLAvZgKgwhuUPaVIgaiwsikHBUCvFA2VYD7L 5iI/u7beDmWmikoOToIvM3JtYCKKxiNL3Zu4HbER5OghCxBIftdHEekQe4m3FLZQifvC zLjg2YIPOolsNG1CTCN+io5iwraOQ4ShRdZ+aX/3dX8MJqpgg5hJ5K83IthdOo0XVB+7 /U/w== 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=YFNA4ELam5YRUPxAgIQjtApdkuuJ6lQE0Iae69YHCAM=; b=jTPOjXjVJwPUyjuwoWTxzSmgFx121ibVJHBeYumkYuqvz7+X8fcnCPMW86lWHFMsHv s7RHkc2jNhJpM+ZFgxvroIjE+HJY8y69zolezW1EGDpQ/pdUlnJeeSU03+YDgM+lDe9p YpdbRcamHUjjtEDaIu7FuuOtqPeOPThNx6QSt8/yJLgNU4stOknNyQe+BXL4RAuRbB1r LxLY/mOFOlx4pNTdYoUlmQJFuU/exwF1FpV0LhrlKiq9IDPKELIm8DV0pK0QWtV9lCoB tvGkCTbdQvitpzSYNaXKRvDsMM1EoT8xVUSSCTZr1J3TRZnYcd741/+hZHuRXzQ+qeoA Wwqg== X-Gm-Message-State: AMke39ltqEj3ii8ge3SQe1TkYvqgQfKs6CDtMxctc9rzM74bH2BSAiCobZobmL/pvfvZEg== X-Received: by 10.55.137.69 with SMTP id l66mr37350504qkd.133.1487853089069; Thu, 23 Feb 2017 04:31:29 -0800 (PST) Received: from localhost.localdomain.com ([2001:1284:f002:49db:6473:3053:4c9e:35b4]) by smtp.gmail.com with ESMTPSA id u54sm2616362qtu.35.2017.02.23.04.31.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Feb 2017 04:31:28 -0800 (PST) From: Marcelo Ricardo Leitner To: netdev@vger.kernel.org Cc: linux-sctp@vger.kernel.org, Vlad Yasevich , Neil Horman , Xin Long , Alexander Popov , Ben Hutchings Subject: [PATCH net] sctp: deny peeloff operation on asocs with threads sleeping on it Date: Thu, 23 Feb 2017 09:31:18 -0300 Message-Id: X-Mailer: git-send-email 2.9.3 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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 --- Hi, please consider this one for -stable too. Thanks 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 1b5d669e30292a57ed57dd920d81be2a57f97b22..d04a8b66098c8a574642b026bff990ac64c21468 100644 --- a/net/sctp/socket.c +++ b/net/sctp/socket.c @@ -4734,6 +4734,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. */ @@ -7426,8 +7432,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;