Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B08F1C6FD19 for ; Mon, 13 Mar 2023 14:55:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231499AbjCMOzU (ORCPT ); Mon, 13 Mar 2023 10:55:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33600 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231279AbjCMOyw (ORCPT ); Mon, 13 Mar 2023 10:54:52 -0400 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E3D1F83C1; Mon, 13 Mar 2023 07:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1678719268; x=1710255268; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=nWyVkNca+rSYnnhnxhsyHqJhvIyoVCvZWVEP37M7+mg=; b=BFIBWh6KDEukB8Bi/0o4qNms7Lg4odJS6WYl/cFu8qwkcPdCyl3U50B0 0y7/h9j0HzutDvibkB+pkVwejiMBgN9Gr3kQ2lpgFk271vSgBt7DZll9l qsaaNx9uF/GyBz24kxkflhwCNbCodxlT8rWF6PykgSu2MUrHoyEkZlyzv PUaAXdbKVE6sLNAOelxJSBVq54qtZrHrTwXIoMbLm2MbGsDrB/9udSIN4 FTTYlRX8Gpp3oiHS5PP8gDvYgIyICpzVNfTatKsAExlbk8KmkhjOPZFDA Bt90F7i+bGyK4t4FpHIM2yH8yWtkBKzWEkJnwKLGCz6WYH5jNt2UpONC6 Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10648"; a="337186810" X-IronPort-AV: E=Sophos;i="5.98,257,1673942400"; d="scan'208";a="337186810" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Mar 2023 07:53:31 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10648"; a="681066548" X-IronPort-AV: E=Sophos;i="5.98,257,1673942400"; d="scan'208";a="681066548" Received: from unknown (HELO localhost.localdomain) ([10.237.112.144]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Mar 2023 07:53:28 -0700 Date: Mon, 13 Mar 2023 15:53:20 +0100 From: Michal Swiatkowski To: Zheng Wang Cc: ericvh@gmail.com, lucho@ionkov.net, asmadeus@codewreck.org, linux_oss@crudebyte.com, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, v9fs-developer@lists.sourceforge.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, hackerzheng666@gmail.com, 1395428693sheep@gmail.com, alex000young@gmail.com Subject: Re: [PATCH net v3] 9p/xen : Fix use after free bug in xen_9pfs_front_remove due to race condition Message-ID: References: <20230313144325.3622082-1-zyytlz.wz@163.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230313144325.3622082-1-zyytlz.wz@163.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 13, 2023 at 10:43:25PM +0800, Zheng Wang wrote: > In xen_9pfs_front_probe, it calls xen_9pfs_front_alloc_dataring > to init priv->rings and bound &ring->work with p9_xen_response. > > When it calls xen_9pfs_front_event_handler to handle IRQ requests, > it will finally call schedule_work to start the work. > > When we call xen_9pfs_front_remove to remove the driver, there > may be a sequence as follows: > > Fix it by finishing the work before cleanup in xen_9pfs_front_free. > > Note that, this bug is found by static analysis, which might be > false positive. > > CPU0 CPU1 > > |p9_xen_response > xen_9pfs_front_remove| > xen_9pfs_front_free| > kfree(priv) | > //free priv | > |p9_tag_lookup > |//use priv->client > > Fixes: 71ebd71921e4 ("xen/9pfs: connect to the backend") > Signed-off-by: Zheng Wang > --- > v3: > - remove unnecessary comment and move definition to the > for loop suggested by Michal Swiatkowski > > v2: > - fix type error of ring found by kernel test robot > --- > net/9p/trans_xen.c | 4 ++++ > 1 file changed, 4 insertions(+) > [...] Thanks for changes Reviewed-by: Michal Swiatkowski