Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp3869338ybz; Mon, 4 May 2020 11:12:22 -0700 (PDT) X-Google-Smtp-Source: APiQypKaf8BLXwjGbERrPzEUiUDtmyAYZgkvvE90wZgN9RHB9dX5JDR+e3p1B8Lxvdw7f74Z3Kwv X-Received: by 2002:a17:906:1a06:: with SMTP id i6mr15783960ejf.90.1588615942749; Mon, 04 May 2020 11:12:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588615942; cv=none; d=google.com; s=arc-20160816; b=icgQL2gihV83YqQsNktZUNdtbMKZJKYyhNKXwEbmovE/wj9GPagHBuB1ddueqrk3xV OTQkYYxwuNCs3gyz+KkTjaK0uM5c2TA92qGnn7neElCaG4M5hw9taAdQC3UZe5q8pa4b rThRiuaAc6Sw6tCfq1cME75i8PsWek4bYsFmoIX6nmAK45mxkkEHun7REEE7IcGO9QP0 QfKkHYzgKl4dQB4F/db/bUBtL4t9nRcFotllNkzKFkqaKunT2fk73WyI/L7yDhxeHMIc gWhDa1VjBpdfkgCiQhCzoVyjiudXgvSiw1U5oAw9oBm+lw8Nrz69mNqrlTGGko95HFJ8 wwHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=Izq4cJxgxRD51I7vVxsMKkLunrQob4qSmoYmefvkZMY=; b=O49nbH0KBIcZ94LDk8ErHxOoujDz60YI0CoCk3XUZ1ltgluHHuhu3fDJN56yeuxel7 unP5kIV9uv/jBx0wNOiILyIsZDSN/uhS0lxyPxe06MABQXhd320yzMrWA95S7b6ofB9E /AuWoQhiOHkm8kKdcpS/8BSHGEzRBdAVTxWx29qL+V0NzvDy4ZpiOZNNp7qLsCU0YYBy VICgfr6Ht7bO8wAs+Kvc1x7xHQes/e6RHZOWsB8x1xnCuuQn7u6ysApa5DD9xG47m4jD NUJb5MnR0Hz4RF6/A23R8yWry8aLysMxNhlhWzXCeDOTT0tooyEKTE9pPUdNzHDkvG7C /oXA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="Sah/UtS8"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cm13si6705145edb.48.2020.05.04.11.11.57; Mon, 04 May 2020 11:12:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="Sah/UtS8"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732018AbgEDSGq (ORCPT + 99 others); Mon, 4 May 2020 14:06:46 -0400 Received: from mail.kernel.org ([198.145.29.99]:37250 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732010AbgEDSGo (ORCPT ); Mon, 4 May 2020 14:06:44 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C20DB2087E; Mon, 4 May 2020 18:06:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588615604; bh=w+yPL/bVXvDTiFWPzUWODEVmw/6jrMVQG1TYGt8QO3s=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Sah/UtS8oGuKUF2WBmfxkf+XAVobMbiRMf3gNRU4fmcdBzY1373TJqQnJe5S1QFx6 I92d0MAnVZTi7IPgfGUxKrUj0JDTqkEJKnXjtHotfWw0buoPdOVoCX7HbmTY7Ksayc HXVzdiOffgez5EW8TupfH3M8+hJ5WoPqGHYZVlGE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jason Gunthorpe , Leon Romanovsky Subject: [PATCH 5.6 49/73] RDMA/core: Fix race between destroy and release FD object Date: Mon, 4 May 2020 19:57:52 +0200 Message-Id: <20200504165509.066749063@linuxfoundation.org> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200504165501.781878940@linuxfoundation.org> References: <20200504165501.781878940@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Leon Romanovsky commit f0abc761bbb9418876cc4d1ebc473e4ea6352e42 upstream. The call to ->lookup_put() was too early and it caused an unlock of the read/write protection of the uobject after the FD was put. This allows a race: CPU1 CPU2 rdma_lookup_put_uobject() lookup_put_fd_uobject() fput() fput() uverbs_uobject_fd_release() WARN_ON(uverbs_try_lock_object(uobj, UVERBS_LOOKUP_WRITE)); atomic_dec(usecnt) Fix the code by changing the order, first unlock and call to ->lookup_put() after that. Fixes: 3832125624b7 ("IB/core: Add support for idr types") Link: https://lore.kernel.org/r/20200423060122.6182-1-leon@kernel.org Suggested-by: Jason Gunthorpe Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman --- drivers/infiniband/core/rdma_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/infiniband/core/rdma_core.c +++ b/drivers/infiniband/core/rdma_core.c @@ -678,7 +678,6 @@ void rdma_lookup_put_uobject(struct ib_u enum rdma_lookup_mode mode) { assert_uverbs_usecnt(uobj, mode); - uobj->uapi_object->type_class->lookup_put(uobj, mode); /* * In order to unlock an object, either decrease its usecnt for * read access or zero it in case of exclusive access. See @@ -695,6 +694,7 @@ void rdma_lookup_put_uobject(struct ib_u break; } + uobj->uapi_object->type_class->lookup_put(uobj, mode); /* Pairs with the kref obtained by type->lookup_get */ uverbs_uobject_put(uobj); }