Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3310580imu; Sun, 11 Nov 2018 12:06:46 -0800 (PST) X-Google-Smtp-Source: AJdET5dTNBvwXDxkIV3h0B8kvuFX7uj+gbSdBnSfiRkIGgYVpyer8O21PDXPzXo5EuToLhrf2rTN X-Received: by 2002:a65:4784:: with SMTP id e4mr14686130pgs.12.1541966806785; Sun, 11 Nov 2018 12:06:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541966806; cv=none; d=google.com; s=arc-20160816; b=ihafRKmqTG2VfUKuINw8rI9ovMSi+O67AVsAZc/r+tQaiDZIJ4Jjy1upe017yVR9xx ICZYTOGBYVaSdB3UnlDyHgU/cg9HFpXBUZ9iQlnZ044SMOBgC1i6z6KygDAr7t361SbB EgcSaUojXmubLSj9YPEWR3E+Va94EAb1ge76Gmj5i/a1Pr4UTAXHJHL7pICe6iVvxSy5 kNBpNx1CPkijwdQ/qla3HeRKSiyemKIL9qmnh7NXDvL+ithqYoOx2Lu69E0rKTVoP4Q4 dzzVS/Zvf8GqAhk9TqcEobcBCFGN3+1Q4lDeCknVnCWVUg9JEBk1V5X7pyac3DW2Haa/ 5mOA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=qzNzpTADGSJSIHwv2aC24RFBcg+lO3MqrYagHIV1glE=; b=k/ay2Csi2HwaJL9E4Q6Fe4qyIb5r5HaRDi4waJpvJsarY8kEjttHmGBHkawyewOn8x AySdQnL70Ohd+e3qJQv2z6U+31a13h2z90Iodk6oV2R/lELW/cGz6lQ9vH6G3PuPcpGm U0GXEslrDK18pCqSTZEow4Rgx1eHZjDkic/ODSZq7pK43AKprzpqT9q/OEdqhEJ1yvMr vekdRr9KYQUetVRC5kB1LbyWxvgPbfCNwJQocYBVhKQdrQ1z0CSSta4uaNxJmH3cQ+3m 6bSzC9+eLRcNZpH4u5hl45rKUvomO3KYVD7df/7cuMhUhlkimzJMrfYCkca4T5ku2GoQ sXjQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t3-v6si16004418pfb.247.2018.11.11.12.06.31; Sun, 11 Nov 2018 12:06:46 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731348AbeKLFze (ORCPT + 99 others); Mon, 12 Nov 2018 00:55:34 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:51900 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730739AbeKLFzd (ORCPT ); Mon, 12 Nov 2018 00:55:33 -0500 Received: from [192.168.4.242] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gLvsx-0000oP-8b; Sun, 11 Nov 2018 19:59:07 +0000 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1gLvsU-0001dZ-DB; Sun, 11 Nov 2018 19:58:38 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Leon Romanovsky" , "Noa Osherovich" , "syzkaller" , "Jason Gunthorpe" Date: Sun, 11 Nov 2018 19:49:05 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 198/366] RDMA/uverbs: Protect from attempts to create flows on unsupported QP In-Reply-To: X-SA-Exim-Connect-IP: 192.168.4.242 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.61-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Leon Romanovsky commit 940efcc8889f0d15567eb07fc9fd69b06e366aa5 upstream. Flows can be created on UD and RAW_PACKET QP types. Attempts to provide other QP types as an input causes to various unpredictable failures. The reason is that in order to support all various types (e.g. XRC), we are supposed to use real_qp handle and not qp handle and expect to driver/FW to fail such (XRC) flows. The simpler and safer variant is to ban all QP types except UD and RAW_PACKET, instead of relying on driver/FW. Fixes: 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow through uverbs") Cc: syzkaller Reported-by: Noa Osherovich Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings --- drivers/infiniband/core/uverbs_cmd.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/drivers/infiniband/core/uverbs_cmd.c +++ b/drivers/infiniband/core/uverbs_cmd.c @@ -2740,6 +2740,11 @@ int ib_uverbs_ex_create_flow(struct ib_u goto err_uobj; } + if (qp->qp_type != IB_QPT_UD && qp->qp_type != IB_QPT_RAW_PACKET) { + err = -EINVAL; + goto err_put; + } + flow_attr = kmalloc(sizeof(*flow_attr) + cmd.flow_attr.size, GFP_KERNEL); if (!flow_attr) { err = -ENOMEM;