kernel/linux.git/crypto/authencesn.c, branch v6.1.174

crypto: authencesn - Fix src offset when decrypting in-place

2026-04-30T09:19:11+00:00

commit 1f48ad3b19a9dfc947868edda0bb8e48e5b5a8fa upstream. The src SG list offset wasn't set properly when decrypting in-place, fix it. Reported-by: Wolfgang Walter Fixes: e02494114ebf ("crypto: authencesn - Do not place hiseq at end of dst for out-of-place decryption") Signed-off-by: Herbert Xu Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman

crypto: authencesn - Do not place hiseq at end of dst for out-of-place decryption

2026-04-30T09:19:11+00:00

commit e02494114ebf7c8b42777c6cd6982f113bfdbec7 upstream. When decrypting data that is not in-place (src != dst), there is no need to save the high-order sequence bits in dst as it could simply be re-copied from the source. However, the data to be hashed need to be rearranged accordingly. Reported-by: Taeyang Lee <0wn@theori.io> Fixes: 104880a6b470 ("crypto: authencesn - Convert to new AEAD interface") Signed-off-by: Herbert Xu Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman

crypto: authenc - use memcpy_sglist() instead of null skcipher

2026-04-30T09:19:11+00:00

commit dbc4b1458e931e47198c3165ff5853bc1ad6bd7a upstream. For copying data between two scatterlists, just use memcpy_sglist() instead of the so-called "null skcipher". This is much simpler. Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman

crypto: authencesn - reject too-short AAD (assoclen<8) to match ESP/ESN spec

2026-02-06T15:44:06+00:00

[ Upstream commit 2397e9264676be7794f8f7f1e9763d90bd3c7335 ] authencesn assumes an ESP/ESN-formatted AAD. When assoclen is shorter than the minimum expected length, crypto_authenc_esn_decrypt() can advance past the end of the destination scatterlist and trigger a NULL pointer dereference in scatterwalk_map_and_copy(), leading to a kernel panic (DoS). Add a minimum AAD length check to fail fast on invalid inputs. Fixes: 104880a6b470 ("crypto: authencesn - Convert to new AEAD interface") Reported-By: Taeyang Lee <0wn@theori.io> Signed-off-by: Taeyang Lee <0wn@theori.io> Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

crypto: algapi - use common mechanism for inheriting flags

2020-07-16T11:49:08+00:00

The flag CRYPTO_ALG_ASYNC is "inherited" in the sense that when a template is instantiated, the template will have CRYPTO_ALG_ASYNC set if any of the algorithms it uses has CRYPTO_ALG_ASYNC set. We'd like to add a second flag (CRYPTO_ALG_ALLOCATES_MEMORY) that gets "inherited" in the same way. This is difficult because the handling of CRYPTO_ALG_ASYNC is hardcoded everywhere. Address this by: - Add CRYPTO_ALG_INHERITED_FLAGS, which contains the set of flags that have these inheritance semantics. - Add crypto_algt_inherited_mask(), for use by template ->create() methods. It returns any of these flags that the user asked to be unset and thus must be passed in the 'mask' to crypto_grab_*(). - Also modify crypto_check_attr_type() to handle computing the 'mask' so that most templates can just use this. - Make crypto_grab_*() propagate these flags to the template instance being created so that templates don't have to do this themselves. Make crypto/simd.c propagate these flags too, since it "wraps" another algorithm, similar to a template. Based on a patch by Mikulas Patocka (https://lore.kernel.org/r/alpine.LRH.2.02.2006301414580.30526@file01.intranet.prod.int.rdu2.redhat.com). Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: authencesn - fix weird comma-terminated line

2020-03-06T01:28:22+00:00

Fix a weird case where a line was terminated by a comma rather than a semicolon, causing the statement to be continued on the next line. Fortunately the code still behaved as intended, though. Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: authencesn - use crypto_grab_ahash() and simplify error paths

2020-01-09T03:30:55+00:00

Make the authencesn template use the new function crypto_grab_ahash() to initialize its ahash spawn. This is needed to make all spawns be initialized in a consistent way. Also simplify the error handling by taking advantage of crypto_drop_*() now accepting (as a no-op) spawns that haven't been initialized yet, and by taking advantage of crypto_grab_*() now handling ERR_PTR() names. Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: skcipher - pass instance to crypto_grab_skcipher()

2020-01-09T03:30:54+00:00

Initializing a crypto_skcipher_spawn currently requires: 1. Set spawn->base.inst to point to the instance. 2. Call crypto_grab_skcipher(). But there's no reason for these steps to be separate, and in fact this unneeded complication has caused at least one bug, the one fixed by commit 6db43410179b ("crypto: adiantum - initialize crypto_spawn::inst") So just make crypto_grab_skcipher() take the instance as an argument. To keep the function calls from getting too unwieldy due to this extra argument, also introduce a 'mask' variable into the affected places which weren't already using one. Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: remove propagation of CRYPTO_TFM_RES_* flags

2020-01-09T03:30:53+00:00

The CRYPTO_TFM_RES_* flags were apparently meant as a way to make the ->setkey() functions provide more information about errors. But these flags weren't actually being used or tested, and in many cases they weren't being set correctly anyway. So they've now been removed. Also, if someone ever actually needs to start better distinguishing ->setkey() errors (which is somewhat unlikely, as this has been unneeded for a long time), we'd be much better off just defining different return values, like -EINVAL if the key is invalid for the algorithm vs. -EKEYREJECTED if the key was rejected by a policy like "no weak keys". That would be much simpler, less error-prone, and easier to test. So just remove CRYPTO_TFM_RES_MASK and all the unneeded logic that propagates these flags around. Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: remove CRYPTO_TFM_RES_BAD_KEY_LEN

2020-01-09T03:30:53+00:00

The CRYPTO_TFM_RES_BAD_KEY_LEN flag was apparently meant as a way to make the ->setkey() functions provide more information about errors. However, no one actually checks for this flag, which makes it pointless. Also, many algorithms fail to set this flag when given a bad length key. Reviewing just the generic implementations, this is the case for aes-fixed-time, cbcmac, echainiv, nhpoly1305, pcrypt, rfc3686, rfc4309, rfc7539, rfc7539esp, salsa20, seqiv, and xcbc. But there are probably many more in arch/*/crypto/ and drivers/crypto/. Some algorithms can even set this flag when the key is the correct length. For example, authenc and authencesn set it when the key payload is malformed in any way (not just a bad length), the atmel-sha and ccree drivers can set it if a memory allocation fails, and the chelsio driver sets it for bad auth tag lengths, not just bad key lengths. So even if someone actually wanted to start checking this flag (which seems unlikely, since it's been unused for a long time), there would be a lot of work needed to get it working correctly. But it would probably be much better to go back to the drawing board and just define different return values, like -EINVAL if the key is invalid for the algorithm vs. -EKEYREJECTED if the key was rejected by a policy like "no weak keys". That would be much simpler, less error-prone, and easier to test. So just remove this flag. Signed-off-by: Eric Biggers Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu