Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp887051iog; Fri, 24 Jun 2022 17:09:17 -0700 (PDT) X-Google-Smtp-Source: AGRyM1u08bZNBXsNLw9N6ooV8nuda1mPOwVegi6oxdRzEmA1lY9aMeOLASnRMm1aQo6mFbsWIAPS X-Received: by 2002:a17:906:9b93:b0:722:f3e8:3f5e with SMTP id dd19-20020a1709069b9300b00722f3e83f5emr1508255ejc.65.1656115757347; Fri, 24 Jun 2022 17:09:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656115757; cv=none; d=google.com; s=arc-20160816; b=q0thRusIMkt5/YS1+Atk32cJ35FASU6GaCVJMVvX54DD0xZerGsmefJL7cPL3MZ1TQ 5GVC6TJuiY7n9q8lrvRXWe+IaJ/3IVAbDZWdCOMWr2g5B2ROEx/j9/IS0xyV/VtHSz4l IahpBZOmSjQqY8jMZrHqbmDR4Lh5HugYaXnmljHCT27xwfIGnA269SpJ6sAwVBFU+I9o PL+aw4xvP6GcY7EiaPLf8FCucoRatwUtb9HjUFUCCCHn9ILEt628cd3vKI57ilm2Tzrh pVFodF4fUtbR5xvjBlapL1MTKSsZKjeb+jA2Ao+8mo0OqT/0JYLFcjBEPg5bZ63CYm7I E9rA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=Pwy5+IbWB0Gv7cf31+Y3t0l2KlHbfsHccSIudADSFZA=; b=oU2Avo6YKZ2KTxgeU8LS/T+wAlWkwuY7YHfgBeBN5GSbap6sEaTAwYWoeNqaCOxKPj 4OzU3Wewe+4n+/lxR1Hw9sRNV7V2JEnXdINZQYhhtveUhjoYXXkzDahfhYcz3/l4H0U9 bVE1y29sF5qY99vWby6mCXiz47tTXbFkpUe8a3yO7Tzc1by2OLy/1XDlaHMRD2WIq4Nb WbKKrtx/gUKkkNe7ap0yUYNS1KtVD2YRydyzoby5Jp4EQkxHqBTtqT8qHtW4PIB1/WMP rYha36zUP6DgEfmSBPbuSNCwnBrdOqEPl5rYiax1bjOTtXVZln2o3CIF817fxR3AF+fN cmmw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=acm.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l25-20020a1709062a9900b0071216b08163si1824104eje.264.2022.06.24.17.08.52; Fri, 24 Jun 2022 17:09:17 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=acm.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232002AbiFXX5x (ORCPT + 99 others); Fri, 24 Jun 2022 19:57:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49792 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231995AbiFXX5v (ORCPT ); Fri, 24 Jun 2022 19:57:51 -0400 Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CD48B8BEED; Fri, 24 Jun 2022 16:57:50 -0700 (PDT) Received: by mail-pj1-f51.google.com with SMTP id a11-20020a17090acb8b00b001eca0041455so6306737pju.1; Fri, 24 Jun 2022 16:57:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=Pwy5+IbWB0Gv7cf31+Y3t0l2KlHbfsHccSIudADSFZA=; b=dO2VxgzjuhENjb08SWTFCW2dp7c3F7RJI7FXzC37Qj91RbWKaahSm7Je6s/aAiWdnh dip53YtcXzxUtmNHncaiQkiB+wQiZyxTtjv3K4LFyJFYXEei07B+w+vatXa01clTAnEj YSu5tqxIQNwMqQF28n4cnjWePH8nYn6gSBzcC3fRkSzMCxkdk/xrOaNFuBwHa7VkTrWw pZ5jfdaGCKojQ+pEdPdnG9BXVESqoz/OOSocZ2wtZEzYQgOgcYXtGTbtRmrdaDeAkJI7 InGFDSdeg2lU2fqfTAKVWTZySf0AKlMlTte1uBQCKRdHx+E2OtavG81YHJKfOOul7CV1 ifGw== X-Gm-Message-State: AJIora801NgmKDfR6+46ipYDuhuliktcR90DB+Vcz79GZsOqLH68KS1J o6/4PdTbt5ic6OhKaBbbDeI= X-Received: by 2002:a17:902:8342:b0:16a:39e6:5acd with SMTP id z2-20020a170902834200b0016a39e65acdmr1571816pln.32.1656115070114; Fri, 24 Jun 2022 16:57:50 -0700 (PDT) Received: from ?IPV6:2620:15c:211:201:4e1:3e2c:e2fe:b5e0? ([2620:15c:211:201:4e1:3e2c:e2fe:b5e0]) by smtp.gmail.com with ESMTPSA id 3-20020a17090a08c300b001ed1444df67sm3491240pjn.6.2022.06.24.16.57.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Jun 2022 16:57:49 -0700 (PDT) Message-ID: <0d6ffcec-285a-37f8-5f2f-6a16e3631b92@acm.org> Date: Fri, 24 Jun 2022 16:57:47 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [RFC PATCH] RDMA/srp: Fix use-after-free in srp_exit_cmd_priv Content-Language: en-US To: Jason Gunthorpe Cc: Li Zhijian , Leon Romanovsky , linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org References: <20220624040253.1420844-1-lizhijian@fujitsu.com> <20220624225908.GA303931@nvidia.com> <5a4a42fe-c5c8-63fe-365f-e6c74a279cc2@acm.org> <20220624234757.GD4147@nvidia.com> From: Bart Van Assche In-Reply-To: <20220624234757.GD4147@nvidia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS,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: X-Mailing-List: linux-kernel@vger.kernel.org On 6/24/22 16:47, Jason Gunthorpe wrote: > 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 That sounds like an interesting approach to me. Li, do you perhaps want to implement this approach? Thanks, Bart.