crypto: hash - set CRYPTO_TFM_NEED_KEY if ->setkey() fails
authorEric Biggers <ebiggers@google.com>
Mon, 7 Jan 2019 02:47:42 +0000 (18:47 -0800)
committerHerbert Xu <herbert@gondor.apana.org.au>
Fri, 18 Jan 2019 10:40:24 +0000 (18:40 +0800)
commitba7d7433a0e998c902132bd47330e355a1eaa894
tree173b444702f5d2114d687711b3376477dbbde26b
parent6b476662b09c393936e0f62c97ad9988d410fd36
crypto: hash - set CRYPTO_TFM_NEED_KEY if ->setkey() fails

Some algorithms have a ->setkey() method that is not atomic, in the
sense that setting a key can fail after changes were already made to the
tfm context.  In this case, if a key was already set the tfm can end up
in a state that corresponds to neither the old key nor the new key.

It's not feasible to make all ->setkey() methods atomic, especially ones
that have to key multiple sub-tfms.  Therefore, make the crypto API set
CRYPTO_TFM_NEED_KEY if ->setkey() fails and the algorithm requires a
key, to prevent the tfm from being used until a new key is set.

Note: we can't set CRYPTO_TFM_NEED_KEY for OPTIONAL_KEY algorithms, so
->setkey() for those must nevertheless be atomic.  That's fine for now
since only the crc32 and crc32c algorithms set OPTIONAL_KEY, and it's
not intended that OPTIONAL_KEY be used much.

[Cc stable mainly because when introducing the NEED_KEY flag I changed
 AF_ALG to rely on it; and unlike in-kernel crypto API users, AF_ALG
 previously didn't have this problem.  So these "incompletely keyed"
 states became theoretically accessible via AF_ALG -- though, the
 opportunities for causing real mischief seem pretty limited.]

Fixes: 9fa68f620041 ("crypto: hash - prevent using keyed hashes without setting key")
Cc: stable@vger.kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
crypto/ahash.c
crypto/shash.c