From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 83D8AC433DF for ; Sun, 21 Jun 2020 07:12:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5818624844 for ; Sun, 21 Jun 2020 07:12:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592723555; bh=Z+QJGF0WzCBKj4J91I+6z8NCJI6iL5RWmILWL2hWspQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=wkYFBxi0qPqCo/DO1zCo2HrQYe1Na/v8mGFENgOt32nq7boQINTlNXj+jJGLs5mle jUPGg42SQgHnFhEo/H4zmJzjkXEpACqqVgGTtq5wkFOVWKQrItXPMQD7yJJXpTnj/3 8I29/MLU7ZdoN8XnNDF97kjk5pzZZDQq4Sk8OdZc= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729420AbgFUHMb (ORCPT ); Sun, 21 Jun 2020 03:12:31 -0400 Received: from mail.kernel.org ([198.145.29.99]:60076 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729381AbgFUHMb (ORCPT ); Sun, 21 Jun 2020 03:12:31 -0400 Received: from localhost (unknown [213.57.247.131]) (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 379DE24844; Sun, 21 Jun 2020 07:12:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592723550; bh=Z+QJGF0WzCBKj4J91I+6z8NCJI6iL5RWmILWL2hWspQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=m7NO7dVdORmug87M+76ahS95y3bwUuPiQePyQ259x8Ml46zA5QYz/SwnfMk6PqXj4 rNgfYA2I1Lw1B3QXoUTCKs8Spos7QL7Q613KU8VllRAYSvcmNrU4NVdYAH2CJHRd3w X6ex9YAr5MIaXruiK4v4baawuEgKl4jD0OKs5rRY= Date: Sun, 21 Jun 2020 10:12:27 +0300 From: Leon Romanovsky To: Jason Gunthorpe Cc: Divya Indi , linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, Kaike Wan , Gerd Rausch , =?iso-8859-1?Q?H=E5kon?= Bugge , Srinivas Eeda , Rama Nichanamatlu , Doug Ledford Subject: Re: [PATCH v3] IB/sa: Resolving use-after-free in ib_nl_send_msg Message-ID: <20200621071227.GA6698@unreal> References: <1591627576-920-1-git-send-email-divya.indi@oracle.com> <1591627576-920-2-git-send-email-divya.indi@oracle.com> <20200609070026.GJ164174@unreal> <20200614064156.GB2132762@unreal> <09bbe749-7eb2-7caa-71a9-3ead4e51e5ed@oracle.com> <20200617051739.GH2383158@unreal> <20200617182300.GJ6578@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200617182300.GJ6578@ziepe.ca> Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org On Wed, Jun 17, 2020 at 03:23:00PM -0300, Jason Gunthorpe wrote: > On Wed, Jun 17, 2020 at 08:17:39AM +0300, Leon Romanovsky wrote: > > > > My thoughts that everything here hints me that state machine and > > locking are implemented wrongly. In ideal world, the expectation > > is that REQ message will have a state in it (PREPARED, SENT, ACK > > e.t.c.) and list manipulations are done accordingly with proper > > locks, while rdma_nl_multicast() is done outside of the locks. > > It can't be done outside the lock without creating races - once > rdma_nl_multicast happens it is possible for the other leg of the > operation to begin processing. It means that the state machine is wrong, not complete. > > The list must be updated before this happens. > > What is missing here is refcounting - the lifetime model of this data > is too implicit, but it is not worth adding I think I have same feeling for now, but it will flip if new fixes be in this area. Thanks > > Jason