All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Berger <stefanb@linux.ibm.com>
To: Lino Sanfilippo <LinoSanfilippo@gmx.de>,
	peterhuewe@gmx.de, jarkko@kernel.org, jgg@ziepe.ca
Cc: p.rosenberger@kunbus.com, linux-integrity@vger.kernel.org,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v2] tpm: fix potential NULL pointer access in tpm_del_char_device
Date: Tue, 21 Dec 2021 23:53:05 -0500	[thread overview]
Message-ID: <af847879-0f29-08e7-7609-da3b27381d3a@linux.ibm.com> (raw)
In-Reply-To: <20211220150635.8545-1-LinoSanfilippo@gmx.de>


On 12/20/21 10:06, Lino Sanfilippo wrote:
> Some SPI controller drivers unregister the controller in the shutdown
> handler (e.g. BCM2835). If such a controller is used with a TPM 2 slave
> chip->ops may be accessed when it is already NULL:
>
> At system shutdown the pre-shutdown handler tpm_class_shutdown() shuts down
> TPM 2 and sets chip->ops to NULL. Then at SPI controller unregistration
> tpm_tis_spi_remove() is called and eventually calls tpm_del_char_device()
> which tries to shut down TPM 2 again. Thereby it accesses chip->ops again:
> (tpm_del_char_device calls tpm_chip_start which calls tpm_clk_enable which
> calls chip->ops->clk_enable).
>
> Avoid the NULL pointer access by testing if chip->ops is valid and skipping
> the TPM 2 shutdown procedure in case it is NULL.
>
> Fixes: dcbeab1946454 ("tpm: fix crash in tpm_tis deinitialization")
> Cc: stable@vger.kernel.org
> Signed-off-by: Lino Sanfilippo <LinoSanfilippo@gmx.de>
> ---
>
> Changes to v2:
> - rephrased the commit message to clarify the circumstances under which
>    this bug triggers (as requested by Jarkko)
>
>
> I was able to reproduce this issue with a SLB 9670 TPM chip controlled by
> a BCM2835 SPI controller.
>
> The approach to fix this issue in the BCM2835 driver was rejected after a
> discussion on the mailing list:
>
> https://marc.info/?l=linux-integrity&m=163285906725367&w=2
>
> The reason for the rejection was the realization, that this issue should rather
> be fixed in the TPM code:
>
> https://marc.info/?l=linux-spi&m=163311087423271&w=2
>
> So this is the reworked version of a patch that is supposed to do that.
>
>
>   drivers/char/tpm/tpm-chip.c | 16 +++++++++++-----
>   1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
> index ddaeceb7e109..7960da490e72 100644
> --- a/drivers/char/tpm/tpm-chip.c
> +++ b/drivers/char/tpm/tpm-chip.c
> @@ -474,13 +474,19 @@ static void tpm_del_char_device(struct tpm_chip *chip)
>   
>   	/* Make the driver uncallable. */
>   	down_write(&chip->ops_sem);
> -	if (chip->flags & TPM_CHIP_FLAG_TPM2) {
> -		if (!tpm_chip_start(chip)) {
> -			tpm2_shutdown(chip, TPM2_SU_CLEAR);
> -			tpm_chip_stop(chip);
> +	/* Check if chip->ops is still valid: In case that the controller
> +	 * drivers shutdown handler unregisters the controller in its
> +	 * shutdown handler we are called twice and chip->ops to NULL.
> +	 */
> +	if (chip->ops) {
> +		if (chip->flags & TPM_CHIP_FLAG_TPM2) {
> +			if (!tpm_chip_start(chip)) {
> +				tpm2_shutdown(chip, TPM2_SU_CLEAR);
> +				tpm_chip_stop(chip);
> +			}
>   		}
> +		chip->ops = NULL;
>   	}
> -	chip->ops = NULL;
>   	up_write(&chip->ops_sem);
>   }
>   
>
> base-commit: a7904a538933c525096ca2ccde1e60d0ee62c08e


Fixes: 39d0099f9439 ("powerpc/pseries: Add shutdown() to vio_driver and 
vio_bus")

Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>

Tested-by: Stefan Berger <stefanb@linux.ibm.com>



  parent reply	other threads:[~2021-12-22  4:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-20 15:06 [PATCH v2] tpm: fix potential NULL pointer access in tpm_del_char_device Lino Sanfilippo
2021-12-21 19:16 ` Lino Sanfilippo
2021-12-22  4:53 ` Stefan Berger [this message]
2021-12-22  6:56   ` Lino Sanfilippo
2021-12-29  0:13 ` Jarkko Sakkinen
2021-12-29  1:41   ` Lino Sanfilippo
2021-12-29  1:46     ` Jarkko Sakkinen
2021-12-29  1:51       ` Lino Sanfilippo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=af847879-0f29-08e7-7609-da3b27381d3a@linux.ibm.com \
    --to=stefanb@linux.ibm.com \
    --cc=LinoSanfilippo@gmx.de \
    --cc=jarkko@kernel.org \
    --cc=jgg@ziepe.ca \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=p.rosenberger@kunbus.com \
    --cc=peterhuewe@gmx.de \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.