Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp1678374ybh; Tue, 14 Jul 2020 04:36:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwwUeuFgbfNjSLmP5CTMMADt1o+R1GY2AKfNCusLi37iixKPfxpuDYzBFLotVR339I4BWka X-Received: by 2002:aa7:ca05:: with SMTP id y5mr4172098eds.204.1594726560869; Tue, 14 Jul 2020 04:36:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594726560; cv=none; d=google.com; s=arc-20160816; b=fBRwVFiUzCkPaq5AGrKrisbi24WkKoYqUDPQqsujxE/V2BTMzpzB2DdcUO1xKmKtpg zZyMH8BPervYLEEc1Rw900WsDXX3PCIxZxenFUQvE9RwDf1sSIBIPj6tGzzBq6JasY2F ZrxYg/8jJtO7YDcBxQ6fqcHvlxQxjJhKQEq0HCJdF1v3l01kTY9z2IFmfEk/vLY3undy nlp36N3h1BZ6zjz3iuxmh7mFF5J36gLsJPA/czQRhw/Eamq4YoBtTGLJBkHur+ITBY0P VK/yqNPb4JU+q+1/8HP+LiF/LEgDOiHmOUrZglDQyPwdREtm42eFZWZhjK5IQAsb3qqq +gGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:organization:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:ironport-sdr:ironport-sdr; bh=GydKH4gt+nuwzYo/EXQFDBRJ619PToQO2+q9Cs+/dp0=; b=dMizbZhy3/yzOYQBzR/lPgIPPBiEOLHT6/tJuABuQxsIO4VAS1JQberX58Ks9zezCS U6cOu2QgFss6tVeA0tPWOvTJMjBTFCfbhyaq+JFp67r89O6Tfw/zAoNibUgDluS1bKVw oiszwtlHXpYEm131wcbsg0j2eNW3X5NgfDf1Bf+SnuSqm5SGiEk9lQcl28d6uUn6/N9I edXvnK3YF6OrFp82R2Djf+87iPO21qZrrbo2XdwncjCy7UnNdHYPx3Dhi73nOgW6FAuS upMW+FyoKrG4xd5dxE5EeTHGystwct9bVQ74GIViE8M3Bpkt4Dl+1Hc8pQHOXaU0zafu Y5Kg== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t24si10637894ejr.733.2020.07.14.04.35.36; Tue, 14 Jul 2020 04:36:00 -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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727949AbgGNLcW (ORCPT + 99 others); Tue, 14 Jul 2020 07:32:22 -0400 Received: from mga04.intel.com ([192.55.52.120]:11815 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726955AbgGNLcW (ORCPT ); Tue, 14 Jul 2020 07:32:22 -0400 IronPort-SDR: 9SvU/VmHhj1Bhtqb6bFG3qThfdr2LWmauSqfATvJ5ihOPCU5KOfai+mZamhpaPl+zH6Tstg4Dq 5RpzArccsoUw== X-IronPort-AV: E=McAfee;i="6000,8403,9681"; a="146352639" X-IronPort-AV: E=Sophos;i="5.75,350,1589266800"; d="scan'208";a="146352639" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jul 2020 04:32:21 -0700 IronPort-SDR: mzqaSmRQma0PfCQiiYOh4Iz9toWo5pd5Fl6nhTw+7p9UBRrD/4nnN4lO4DkOmsS8o5j2J9QUdn PyMpsuYZMV9w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,350,1589266800"; d="scan'208";a="324517854" Received: from pipper-mobl1.ger.corp.intel.com (HELO localhost) ([10.249.46.185]) by FMSMGA003.fm.intel.com with ESMTP; 14 Jul 2020 04:32:19 -0700 Date: Tue, 14 Jul 2020 14:32:18 +0300 From: Jarkko Sakkinen To: Andrey Pronin Cc: peterhuewe@gmx.de, jgg@ziepe.ca, linux-integrity@vger.kernel.org, LKML , Guenter Roeck Subject: Re: [PATCH] tpm: avoid accessing cleared ops during shutdown Message-ID: <20200714113205.GA1461506@linux.intel.com> References: <20200710002209.6757-1-apronin@chromium.org> <20200710114000.GD2614@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 10, 2020 at 11:25:44AM -0700, Andrey Pronin wrote: > > Why does not tpm_del_char_device need this? > > "Not" is a typo in the sentence above, right? tpm_del_char_device *does* > need the fix. When tpm_class_shutdown is called it sets chip->ops to > NULL. If tpm_del_char_device is called after that, it doesn't check if > chip->ops is NULL (normal kernel API and char device API calls go > through tpm_try_get_ops, but tpm_del_char_device doesn't) and proceeds to > call tpm2_shutdown(), which tries sending the command and dereferences > chip->ops. It's a typo, yes. Sorry about that. tpm_class_shutdown() is essentially tail of tpm_del_char_device(). To clean things up, I'd suggest dropping tpm_del_char_device() and call tpm_class_shutdown() in tpm_chip_unregisters() along, and open coding things that prepend it in tpm_del_char_device(). /Jarkko