crypto: ccm - fix incompatibility between "ccm" and "ccm_base"
authorEric Biggers <ebiggers@google.com>
Thu, 18 Apr 2019 21:44:27 +0000 (14:44 -0700)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 22 May 2019 05:37:43 +0000 (07:37 +0200)
commita80da82d0840b08188252ae262ef77bdf0b08cff
treef8a727997f8f32a8f77498c943a7389be67fed1a
parentf6de0a3b1e66d544c1e4b28b5e864c574baa6dcc
crypto: ccm - fix incompatibility between "ccm" and "ccm_base"

commit 6a1faa4a43f5fabf9cbeaa742d916e7b5e73120f upstream.

CCM instances can be created by either the "ccm" template, which only
allows choosing the block cipher, e.g. "ccm(aes)"; or by "ccm_base",
which allows choosing the ctr and cbcmac implementations, e.g.
"ccm_base(ctr(aes-generic),cbcmac(aes-generic))".

However, a "ccm_base" instance prevents a "ccm" instance from being
registered using the same implementations.  Nor will the instance be
found by lookups of "ccm".  This can be used as a denial of service.
Moreover, "ccm_base" instances are never tested by the crypto
self-tests, even if there are compatible "ccm" tests.

The root cause of these problems is that instances of the two templates
use different cra_names.  Therefore, fix these problems by making
"ccm_base" instances set the same cra_name as "ccm" instances, e.g.
"ccm(aes)" instead of "ccm_base(ctr(aes-generic),cbcmac(aes-generic))".

This requires extracting the block cipher name from the name of the ctr
and cbcmac algorithms.  It also requires starting to verify that the
algorithms are really ctr and cbcmac using the same block cipher, not
something else entirely.  But it would be bizarre if anyone were
actually using non-ccm-compatible algorithms with ccm_base, so this
shouldn't break anyone in practice.

Fixes: 4a49b499dfa0 ("[CRYPTO] ccm: Added CCM mode")
Cc: stable@vger.kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
crypto/ccm.c