summaryrefslogtreecommitdiffstats
path: root/net/6lowpan/nhc.c
diff options
context:
space:
mode:
authorEric Biggers <ebiggers@google.com>2019-04-18 14:44:27 -0700
committerHerbert Xu <herbert@gondor.apana.org.au>2019-04-19 13:53:13 +0800
commit6a1faa4a43f5fabf9cbeaa742d916e7b5e73120f (patch)
tree425f361f7dab371971766f65fffc28189db11985 /net/6lowpan/nhc.c
parentf699594d436960160f6d5ba84ed4a222f20d11cd (diff)
downloadlinux-6a1faa4a43f5fabf9cbeaa742d916e7b5e73120f.tar.bz2
crypto: ccm - fix incompatibility between "ccm" and "ccm_base"
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>
Diffstat (limited to 'net/6lowpan/nhc.c')
0 files changed, 0 insertions, 0 deletions