From: Greg KH <greg@kroah.com>
To: Eric Biggers <ebiggers@kernel.org>
Cc: stable@vger.kernel.org, linux-crypto@vger.kernel.org
Subject: Re: [PATCH 4.4 2/2] crypto: gcm - fix incompatibility between "gcm" and "gcm_base"
Date: Sat, 18 May 2019 08:56:48 +0200 [thread overview]
Message-ID: <20190518065648.GD28796@kroah.com> (raw)
In-Reply-To: <20190517180610.150453-2-ebiggers@kernel.org>
On Fri, May 17, 2019 at 11:06:10AM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> commit f699594d436960160f6d5ba84ed4a222f20d11cd upstream.
> [Please apply to 4.4-stable.]
>
> GCM instances can be created by either the "gcm" template, which only
> allows choosing the block cipher, e.g. "gcm(aes)"; or by "gcm_base",
> which allows choosing the ctr and ghash implementations, e.g.
> "gcm_base(ctr(aes-generic),ghash-generic)".
>
> However, a "gcm_base" instance prevents a "gcm" instance from being
> registered using the same implementations. Nor will the instance be
> found by lookups of "gcm". This can be used as a denial of service.
> Moreover, "gcm_base" instances are never tested by the crypto
> self-tests, even if there are compatible "gcm" tests.
>
> The root cause of these problems is that instances of the two templates
> use different cra_names. Therefore, fix these problems by making
> "gcm_base" instances set the same cra_name as "gcm" instances, e.g.
> "gcm(aes)" instead of "gcm_base(ctr(aes-generic),ghash-generic)".
>
> This requires extracting the block cipher name from the name of the ctr
> algorithm. It also requires starting to verify that the algorithms are
> really ctr and ghash, not something else entirely. But it would be
> bizarre if anyone were actually using non-gcm-compatible algorithms with
> gcm_base, so this shouldn't break anyone in practice.
>
> Fixes: d00aa19b507b ("[CRYPTO] gcm: Allow block cipher parameter")
> Cc: stable@vger.kernel.org
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> ---
> crypto/gcm.c | 34 +++++++++++-----------------------
> 1 file changed, 11 insertions(+), 23 deletions(-)
Both now queued up, thanks.
greg k-h
prev parent reply other threads:[~2019-05-18 6:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-17 18:06 [PATCH 4.4 1/2] crypto: gcm - Fix error return code in crypto_gcm_create_common() Eric Biggers
2019-05-17 18:06 ` [PATCH 4.4 2/2] crypto: gcm - fix incompatibility between "gcm" and "gcm_base" Eric Biggers
2019-05-18 6:56 ` Greg KH [this message]
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=20190518065648.GD28796@kroah.com \
--to=greg@kroah.com \
--cc=ebiggers@kernel.org \
--cc=linux-crypto@vger.kernel.org \
--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.