All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko@kernel.org>
To: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Cc: peterhuewe@gmx.de, jgg@ziepe.ca, p.rosenberger@kunbus.com,
	linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: Aw: Re: [PATCH] tpm: fix potential NULL pointer access in tpm_del_char_device()
Date: Tue, 14 Sep 2021 03:31:39 +0300	[thread overview]
Message-ID: <c22d2878f9816000c33f5349e7256cadae22b400.camel@kernel.org> (raw)
In-Reply-To: <trinity-27f56ffd-504a-4c34-9cda-0953ccc459a3-1631566430623@3c-app-gmx-bs69>

On Mon, 2021-09-13 at 22:53 +0200, Lino Sanfilippo wrote:
> Hi,
> 
> > Gesendet: Montag, 13. September 2021 um 22:25 Uhr
> > Von: "Jarkko Sakkinen" <jarkko@kernel.org>
> > An: "Lino Sanfilippo" <LinoSanfilippo@gmx.de>, peterhuewe@gmx.de, jgg@ziepe.ca
> > Cc: p.rosenberger@kunbus.com, linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org
> > Betreff: Re: [PATCH] tpm: fix potential NULL pointer access in tpm_del_char_device()
> > 
> > On Fri, 2021-09-10 at 20:04 +0200, Lino Sanfilippo wrote:
> > > In tpm_del_char_device() make sure that chip->ops is still valid.
> > > This check is needed since in case of a system shutdown
> > > tpm_class_shutdown() has already been called and set chip->ops to NULL.
> > > This leads to a NULL pointer access as soon as tpm_del_char_device()
> > > tries to access chip->ops in case of TPM 2.
> > > 
> > > Fixes: dcbeab1946454 ("tpm: fix crash in tpm_tis deinitialization")
> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: Lino Sanfilippo <LinoSanfilippo@gmx.de>
> > > ---
> > 
> > Have you been able to reproduce this in some environment?
> > 
> > /Jarkko
> > 
> > 
> 
> Yes, this bug is reproducable on my system that is running a 5.10 raspberry kernel.
> I use a SLB 9670 which is connected via SPI.

Can you confirm that the lates mainline kernel has also this
issue here? That is lacking in this fix. 

It's obvious that the issue does not scale to every system,
so it would nice to know the difference that triggers the
issue, before applying this, and it also needs to be
documented to the commit message.


/Jarkko

  reply	other threads:[~2021-09-14  0:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-10 18:04 [PATCH] tpm: fix potential NULL pointer access in tpm_del_char_device() Lino Sanfilippo
2021-09-13 20:25 ` Jarkko Sakkinen
2021-09-13 20:53   ` Aw: " Lino Sanfilippo
2021-09-14  0:31     ` Jarkko Sakkinen [this message]
2021-09-24 13:29       ` Lino Sanfilippo
2021-09-24 13:33         ` Jason Gunthorpe
2021-09-24 14:17           ` Lino Sanfilippo
2021-09-24 14:20             ` Jason Gunthorpe
2021-09-29  8:58               ` 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=c22d2878f9816000c33f5349e7256cadae22b400.camel@kernel.org \
    --to=jarkko@kernel.org \
    --cc=LinoSanfilippo@gmx.de \
    --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.