linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Ben Boeckel <me@benboeckel.net>, keyrings@vger.kernel.org
Cc: Ben Boeckel <mathstuf@gmail.com>,
	linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: [PATCH v2 1/1] trusted-keys: match tpm_get_ops on all return paths
Date: Mon, 10 May 2021 16:19:00 -0700	[thread overview]
Message-ID: <c896e4fd24aa649081cb0ce712580a8400ab36d6.camel@HansenPartnership.com> (raw)
In-Reply-To: <YJmf4Q0l+MTFEaEo@erythro.dev.benboeckel.internal>

On Mon, 2021-05-10 at 17:04 -0400, Ben Boeckel wrote:
> On Thu, Apr 29, 2021 at 15:21:56 -0400, Ben Boeckel wrote:
> > From: Ben Boeckel <mathstuf@gmail.com>
> > 
> > The `tpm_get_ops` call at the beginning of the function is not
> > paired
> > with a `tpm_put_ops` on this return path.
> > 
> > Fixes: f2219745250f ("security: keys: trusted: use ASN.1 TPM2 key
> > format for the blobs")
> > Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> > Signed-off-by: Ben Boeckel <mathstuf@gmail.com>
> > ---
> >  security/keys/trusted-keys/trusted_tpm2.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/security/keys/trusted-keys/trusted_tpm2.c
> > b/security/keys/trusted-keys/trusted_tpm2.c
> > index 617fabd4d913..0165da386289 100644
> > --- a/security/keys/trusted-keys/trusted_tpm2.c
> > +++ b/security/keys/trusted-keys/trusted_tpm2.c
> > @@ -336,9 +336,9 @@ int tpm2_seal_trusted(struct tpm_chip *chip,
> >  			rc = -EPERM;
> >  	}
> >  	if (blob_len < 0)
> > -		return blob_len;
> > -
> > -	payload->blob_len = blob_len;
> > +		rc = blob_len;
> > +	else
> > +		payload->blob_len = blob_len;
> >  
> >  	tpm_put_ops(chip);
> >  	return rc;
> 
> Ping? Is this going to make 5.13? This fixes an issue that is in
> 5.13-rc1.

It's not urgent, since it's in an error in the ASN.1 encoder, the only
real way to produce it is if the system runs out of memory, which is
highly unlikely since the allocations are all GFP_KERNEL.  We've also
got another 8 or so weeks before 5.13 so there's time for this to go
through the normal review process.

James



  reply	other threads:[~2021-05-10 23:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-29 19:21 [PATCH v2 0/1] trusted-keys: match tpm_get_ops on all return paths Ben Boeckel
2021-04-29 19:21 ` [PATCH v2 1/1] " Ben Boeckel
2021-05-10 21:04   ` Ben Boeckel
2021-05-10 23:19     ` James Bottomley [this message]
2021-05-11 23:39     ` Jarkko Sakkinen
2021-05-11 23:45     ` Jarkko Sakkinen
2021-05-11 23:58       ` Ben Boeckel

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=c896e4fd24aa649081cb0ce712580a8400ab36d6.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=dan.carpenter@oracle.com \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mathstuf@gmail.com \
    --cc=me@benboeckel.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).