From: Eric Biggers <ebiggers3@gmail.com>
To: Tudor Ambarus <tudor.ambarus@microchip.com>
Cc: linux-crypto@vger.kernel.org,
Herbert Xu <herbert@gondor.apana.org.au>,
keyrings@vger.kernel.org,
Mat Martineau <mathew.j.martineau@linux.intel.com>,
Salvatore Benedetto <salvatore.benedetto@intel.com>,
Stephan Mueller <smueller@chronox.de>,
Eric Biggers <ebiggers@google.com>,
stable@vger.kernel.org
Subject: Re: [PATCH 1/4] crypto: dh - fix double free of ctx->p
Date: Thu, 02 Nov 2017 17:30:01 +0000 [thread overview]
Message-ID: <20171102173001.GA23035@gmail.com> (raw)
In-Reply-To: <93501fc6-94df-bf27-cdd8-7a44b04effc1@microchip.com>
Hi Tudor,
On Thu, Nov 02, 2017 at 12:55:56PM +0200, Tudor Ambarus wrote:
> Hi, Eric,
>
> On 11/02/2017 12:25 AM, Eric Biggers wrote:
> >When setting the secret with the software Diffie-Hellman implementation,
> >if allocating 'g' failed (e.g. if it was longer than
> >MAX_EXTERN_MPI_BITS), then 'p' was freed twice: once immediately, and
> >once later when the crypto_kpp tfm was destroyed. Fix it by using
> >dh_free_ctx() in the error paths, as that sets the pointers to NULL.
>
> Other solution would be to have just an one-line patch that sets p to
> NULL after freeing it. The benefit of just setting p to NULL and not
> using dh_free_ctx() is that you'll spare some cpu cycles. If g fails,
> g and a will already be NULL, so freeing them and set them to NULL is
> redundant.
>
> However, if you decide to always use dh_free_ctx(), you'll have to get
> rid of dh_clear_params(), because it will be used just in dh_free_ctx().
> You can copy dh_clear_params() body to dh_free_ctx().
>
This is on an error path, so a few cycles don't matter. I would much rather
have the simpler code, with less chance to introduce exploitable bugs.
Yes, I should inline dh_clear_params() into dh_free_ctx().
Eric
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers3@gmail.com>
To: Tudor Ambarus <tudor.ambarus@microchip.com>
Cc: linux-crypto@vger.kernel.org,
Herbert Xu <herbert@gondor.apana.org.au>,
keyrings@vger.kernel.org,
Mat Martineau <mathew.j.martineau@linux.intel.com>,
Salvatore Benedetto <salvatore.benedetto@intel.com>,
Stephan Mueller <smueller@chronox.de>,
Eric Biggers <ebiggers@google.com>,
stable@vger.kernel.org
Subject: Re: [PATCH 1/4] crypto: dh - fix double free of ctx->p
Date: Thu, 2 Nov 2017 10:30:01 -0700 [thread overview]
Message-ID: <20171102173001.GA23035@gmail.com> (raw)
In-Reply-To: <93501fc6-94df-bf27-cdd8-7a44b04effc1@microchip.com>
Hi Tudor,
On Thu, Nov 02, 2017 at 12:55:56PM +0200, Tudor Ambarus wrote:
> Hi, Eric,
>
> On 11/02/2017 12:25 AM, Eric Biggers wrote:
> >When setting the secret with the software Diffie-Hellman implementation,
> >if allocating 'g' failed (e.g. if it was longer than
> >MAX_EXTERN_MPI_BITS), then 'p' was freed twice: once immediately, and
> >once later when the crypto_kpp tfm was destroyed. Fix it by using
> >dh_free_ctx() in the error paths, as that sets the pointers to NULL.
>
> Other solution would be to have just an one-line patch that sets p to
> NULL after freeing it. The benefit of just setting p to NULL and not
> using dh_free_ctx() is that you'll spare some cpu cycles. If g fails,
> g and a will already be NULL, so freeing them and set them to NULL is
> redundant.
>
> However, if you decide to always use dh_free_ctx(), you'll have to get
> rid of dh_clear_params(), because it will be used just in dh_free_ctx().
> You can copy dh_clear_params() body to dh_free_ctx().
>
This is on an error path, so a few cycles don't matter. I would much rather
have the simpler code, with less chance to introduce exploitable bugs.
Yes, I should inline dh_clear_params() into dh_free_ctx().
Eric
next prev parent reply other threads:[~2017-11-02 17:30 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-01 22:25 [PATCH 0/4] crypto: dh - input validation fixes Eric Biggers
2017-11-01 22:25 ` Eric Biggers
2017-11-01 22:25 ` [PATCH 1/4] crypto: dh - fix double free of ctx->p Eric Biggers
2017-11-01 22:25 ` Eric Biggers
2017-11-02 10:55 ` Tudor Ambarus
2017-11-02 10:55 ` Tudor Ambarus
2017-11-02 17:30 ` Eric Biggers [this message]
2017-11-02 17:30 ` Eric Biggers
2017-11-01 22:25 ` [PATCH 2/4] crypto: dh - don't permit 'p' to be 0 Eric Biggers
2017-11-01 22:25 ` Eric Biggers
2017-11-02 11:40 ` Tudor Ambarus
2017-11-02 11:40 ` Tudor Ambarus
2017-11-02 17:31 ` Eric Biggers
2017-11-02 17:31 ` Eric Biggers
2017-11-03 6:23 ` Tudor Ambarus
2017-11-03 6:23 ` Tudor Ambarus
2017-11-01 22:25 ` [PATCH 3/4] crypto: qat - fix double free of ctx->p Eric Biggers
2017-11-01 22:25 ` Eric Biggers
2017-11-02 17:34 ` Eric Biggers
2017-11-02 17:34 ` Eric Biggers
2017-11-01 22:25 ` [PATCH 4/4] crypto: dh - don't permit 'key' or 'g' size longer than 'p' Eric Biggers
2017-11-01 22:25 ` Eric Biggers
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=20171102173001.GA23035@gmail.com \
--to=ebiggers3@gmail.com \
--cc=ebiggers@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=keyrings@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=mathew.j.martineau@linux.intel.com \
--cc=salvatore.benedetto@intel.com \
--cc=smueller@chronox.de \
--cc=stable@vger.kernel.org \
--cc=tudor.ambarus@microchip.com \
/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.