Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 24 Jun 2022 20:47:57 -0300
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     Bart Van Assche <bvanassche@acm.org>
Cc:     Li Zhijian <lizhijian@fujitsu.com>,
        Leon Romanovsky <leon@kernel.org>, linux-rdma@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] RDMA/srp: Fix use-after-free in srp_exit_cmd_priv
Message-ID: <20220624234757.GD4147@nvidia.com>
References: <20220624040253.1420844-1-lizhijian@fujitsu.com>
 <20220624225908.GA303931@nvidia.com>
 <5a4a42fe-c5c8-63fe-365f-e6c74a279cc2@acm.org>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5a4a42fe-c5c8-63fe-365f-e6c74a279cc2@acm.org>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?TuRmu/b1eSr0mA5GnD2NdgnKfJRXQBlVlHDhU6PkBXVohsCJ4bIP15J2kPDg?=
 =?us-ascii?Q?F//4coGIRcy78IDurGXuBW9Uoby+iH+mKUuBf8IsFMG/ibJW67QaLEwDpRCb?=
 =?us-ascii?Q?qOU0axo7Gk6u91egDYqN8x4/Uzs16jbtPo1ehD6kJH97rO+WMRBA4qfI6ayP?=
 =?us-ascii?Q?WR7JKw0HWV9/mnHRGAMHqmEEedXkW6G1YmsV1HKpsUHOKDdOSf3S5gZZYu1b?=
 =?us-ascii?Q?FVUIhyvtAbHn82LVvEg/jVcOLkq0NZJCbcQCBpdCzGqJa1LoOloBnVZcpASy?=
 =?us-ascii?Q?hKK9NMW8++373WViVOMn4B7Nlygsz2l/mSvOgslZP2X6tMsCg60AsdQsQfZe?=
 =?us-ascii?Q?beFFFxfgEt8ye2L7GdFNemu7LYTdIQlPAXmZQw9aSvXYRtFk2g7UyAf82Do3?=
 =?us-ascii?Q?6tboCappw6D4xFWqNJiQnTK7+j1KQgyq4e4yau1oKROvzWyXdMC+DRFRVWsF?=
 =?us-ascii?Q?yKji0g6NsWvnC72mm5B+kQU2lcCmxtbGwuZmkVVeETkbCdrPqJ78P63C5uDu?=
 =?us-ascii?Q?khdDYorwaiwlrsOs55wcCb6HJPcWiiJiLYo+1SR5xWe6orPFP8v8/nOmK55X?=
 =?us-ascii?Q?AsEF4zkLeAAKA4u+MKQiEFlkZxcr2rKRgYOS3CYK3yAtexYnE68k35KLePe7?=
 =?us-ascii?Q?zsFveLZBfV8loFxaYsR6Lsa1hanfzMBqf6IBf3dPq4k5W50YYV10poFO9gtj?=
 =?us-ascii?Q?YMAzOvBpY4PfPB1M6XLebZSSSP8PPCxn4Da2Is3WHOd+CQ5DFYwGaB0Pw1tj?=
 =?us-ascii?Q?0AGGXRnSY1KJG9oF37Piwvk1OzmetLKS+YX6Ii42O12Sb+QMNmi8puNyCbZM?=
 =?us-ascii?Q?pHSLeWuR/FokjJt8tLc/vxfOavS3G74d2sK/Wj10EvYhZHFWMa7KGkeVwvFy?=
 =?us-ascii?Q?JCD4Z+6tvQWBRKh3NwG7yiOejNzzYNJp8hsmmEnRwT1rTK8Jn3BF6sT6W2Vf?=
 =?us-ascii?Q?pny2TEPpXpmB1Sl9Atpwbcm24kxrADCDmYDqD9DiIh6VOa4mEOERgC1u3Lge?=
 =?us-ascii?Q?qT6tJmgcGB5Qu696TRMT7EgmVS0/YCI2I6kpRu6u/ECktqayI0sKeh99ZvBp?=
 =?us-ascii?Q?ttOOOG7YlQyM8CSKNhF+CTyNDa25Ig0H7jxOWutRFyFnDPPHy5/pD7N683cM?=
 =?us-ascii?Q?GuTw9Wnqt6C9SVCXzDnMZ+zqGW7c1NCsn6UmaqNc0PeTTHAS9tnWDsQ4X3H+?=
 =?us-ascii?Q?F0OdeG/BjSgGvNUh2TTe0ngP3YcOzbxGOpuTQZ6dBO/7zAsJ+EQWqOvMvUri?=
 =?us-ascii?Q?cZq8FeC25lwOkkshxI2ohujJe+WpLPxVCqxK4PoHUUU8UqVxEOxtilAO0Pv+?=
 =?us-ascii?Q?8X362CO9DRjMXqugPpQdX30mEQW/EYYorCf3TBIpHnxUk1U901AOJpMPkywQ?=
 =?us-ascii?Q?q6SFrrwST9tna3GO3a/2eK4ZmcwIWdRudZjuWTz5r9mdr2m9x+iid1RibhNa?=
 =?us-ascii?Q?nlPm6ZSrmCeFT0Q8drGZ7lW3H7TPptFt3NEE05pmdqHFazndOGNdIEpMyQMg?=
 =?us-ascii?Q?bG9ud6na9injwJbngYRZnoHtwl2HkPpooXypPy6ZAGu/5p3gUKJc4XxzxWCT?=
 =?us-ascii?Q?wFUvPMNEftGiSQ2vB/arC1qSvp+u362yuNDW82z+?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a0b448ee-4b30-491a-6fa7-08da563bf7d4
X-MS-Exchange-CrossTenant-AuthSource: MN2PR12MB4192.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jun 2022 23:47:58.8849
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: ijMDAfg3dz4z1wrdtG2XbJ0LANjY8Bej/a6xHHqCW2S1Fn3dlgY95OvEEM+anxvS
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR12MB3431
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,
        T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Jun 24, 2022 at 04:26:06PM -0700, Bart Van Assche wrote:
> On 6/24/22 15:59, Jason Gunthorpe wrote:
> > I don't even understand how get_device() prevents this call chain??
> > 
> > It looks to me like the problem is srp_remove_one() is not waiting for
> > or canceling some outstanding work.
> 
> Hi Jason,
> 
> My conclusions from the call traces in Li's email are as follows:
> * scsi_host_dev_release() can get called after srp_remove_one().
> * srp_exit_cmd_priv() uses the ib_device pointer. If srp_remove_one() is
> called before srp_exit_cmd_priv() then a use-after-free is triggered.

Shouldn't srp_remove_one() wait for the scsi_host_dev to complete
destruction? Clearly it cannot continue to exist once the IB device
has been removed

> Is calling get_device() and put_device() on the struct ib_device an
> acceptable way to fix this? 

As I said, I don't understand at all how this works. get_device() does
not prevent srp_remove_one() from being called.

Jason