• Eric Biggers's avatar
    crypto: hash - set CRYPTO_TFM_NEED_KEY if ->setkey() fails · 3a48ec70
    Eric Biggers authored
    commit ba7d7433a0e998c902132bd47330e355a1eaa894 upstream.
    
    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: 9fa68f62 ("crypto: hash - prevent using keyed hashes without setting key")
    Cc: stable@vger.kernel.org
    Signed-off-by: 's avatarEric Biggers <ebiggers@google.com>
    Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    3a48ec70