- Linux-stable-mirror - lists.linaro.org

Patch "crypto: x86/cast5-avx - fix ECB encryption when long sg follows short one" has been added to the 4.16-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled crypto: x86/cast5-avx - fix ECB encryption when long sg follows short one to the 4.16-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: crypto-x86-cast5-avx-fix-ecb-encryption-when-long-sg-follows-short-one.patch and it can be found in the queue-4.16 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 8f461b1e02ed546fbd0f11611138da67fd85a30f Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Mon, 19 Feb 2018 23:48:12 -0800 Subject: crypto: x86/cast5-avx - fix ECB encryption when long sg follows short one From: Eric Biggers <ebiggers(a)google.com> commit 8f461b1e02ed546fbd0f11611138da67fd85a30f upstream. With ecb-cast5-avx, if a 128+ byte scatterlist element followed a shorter one, then the algorithm accidentally encrypted/decrypted only 8 bytes instead of the expected 128 bytes. Fix it by setting the encryption/decryption 'fn' correctly. Fixes: c12ab20b162c ("crypto: cast5/avx - avoid using temporary stack buffers") Cc: <stable(a)vger.kernel.org> # v3.8+ Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/crypto/cast5_avx_glue.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/arch/x86/crypto/cast5_avx_glue.c +++ b/arch/x86/crypto/cast5_avx_glue.c @@ -66,8 +66,6 @@ static int ecb_crypt(struct blkcipher_de void (*fn)(struct cast5_ctx *ctx, u8 *dst, const u8 *src); int err; - fn = (enc) ? cast5_ecb_enc_16way : cast5_ecb_dec_16way; - err = blkcipher_walk_virt(desc, walk); desc->flags &= ~CRYPTO_TFM_REQ_MAY_SLEEP; @@ -79,6 +77,7 @@ static int ecb_crypt(struct blkcipher_de /* Process multi-block batch */ if (nbytes >= bsize * CAST5_PARALLEL_BLOCKS) { + fn = (enc) ? cast5_ecb_enc_16way : cast5_ecb_dec_16way; do { fn(ctx, wdst, wsrc); Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-4.16/crypto-x86-cast5-avx-fix-ecb-encryption-when-long-sg-follows-short-one.patch

7 years, 7 months

1
0
0 0

Patch "crypto: testmgr - Fix incorrect values in PKCS#1 test vector" has been added to the 4.16-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled crypto: testmgr - Fix incorrect values in PKCS#1 test vector to the 4.16-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: crypto-testmgr-fix-incorrect-values-in-pkcs-1-test-vector.patch and it can be found in the queue-4.16 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 333e18c5cc74438f8940c7f3a8b3573748a371f9 Mon Sep 17 00:00:00 2001 From: Conor McLoughlin <conor.mcloughlin(a)intel.com> Date: Tue, 13 Feb 2018 08:29:56 +0000 Subject: crypto: testmgr - Fix incorrect values in PKCS#1 test vector From: Conor McLoughlin <conor.mcloughlin(a)intel.com> commit 333e18c5cc74438f8940c7f3a8b3573748a371f9 upstream. The RSA private key for the first form should have version, prime1, prime2, exponent1, exponent2, coefficient values 0. With non-zero values for prime1,2, exponent 1,2 and coefficient the Intel QAT driver will assume that values are provided for the private key second form. This will result in signature verification failures for modules where QAT device is present and the modules are signed with rsa,sha256. Cc: <stable(a)vger.kernel.org> Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu(a)intel.com> Signed-off-by: Conor McLoughlin <conor.mcloughlin(a)intel.com> Reviewed-by: Stephan Mueller <smueller(a)chronox.de> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- crypto/testmgr.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/crypto/testmgr.h +++ b/crypto/testmgr.h @@ -548,7 +548,7 @@ static const struct akcipher_testvec rsa static const struct akcipher_testvec pkcs1pad_rsa_tv_template[] = { { .key = - "\x30\x82\x03\x1f\x02\x01\x10\x02\x82\x01\x01\x00\xd7\x1e\x77\x82" + "\x30\x82\x03\x1f\x02\x01\x00\x02\x82\x01\x01\x00\xd7\x1e\x77\x82" "\x8c\x92\x31\xe7\x69\x02\xa2\xd5\x5c\x78\xde\xa2\x0c\x8f\xfe\x28" "\x59\x31\xdf\x40\x9c\x60\x61\x06\xb9\x2f\x62\x40\x80\x76\xcb\x67" "\x4a\xb5\x59\x56\x69\x17\x07\xfa\xf9\x4c\xbd\x6c\x37\x7a\x46\x7d" @@ -597,8 +597,8 @@ static const struct akcipher_testvec pkc "\xfe\xf8\x27\x1b\xd6\x55\x60\x5e\x48\xb7\x6d\x9a\xa8\x37\xf9\x7a" "\xde\x1b\xcd\x5d\x1a\x30\xd4\xe9\x9e\x5b\x3c\x15\xf8\x9c\x1f\xda" "\xd1\x86\x48\x55\xce\x83\xee\x8e\x51\xc7\xde\x32\x12\x47\x7d\x46" - "\xb8\x35\xdf\x41\x02\x01\x30\x02\x01\x30\x02\x01\x30\x02\x01\x30" - "\x02\x01\x30", + "\xb8\x35\xdf\x41\x02\x01\x00\x02\x01\x00\x02\x01\x00\x02\x01\x00" + "\x02\x01\x00", .key_len = 804, /* * m is SHA256 hash of following message: Patches currently in stable-queue which might be from conor.mcloughlin(a)intel.com are queue-4.16/crypto-testmgr-fix-incorrect-values-in-pkcs-1-test-vector.patch

7 years, 7 months

1
0
0 0

Patch "crypto: talitos - fix IPsec cipher in length" has been added to the 4.16-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled crypto: talitos - fix IPsec cipher in length to the 4.16-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: crypto-talitos-fix-ipsec-cipher-in-length.patch and it can be found in the queue-4.16 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 2b1227301a8e4729409694e323b72c064c47cb6b Mon Sep 17 00:00:00 2001 From: LEROY Christophe <christophe.leroy(a)c-s.fr> Date: Thu, 22 Mar 2018 10:57:01 +0100 Subject: crypto: talitos - fix IPsec cipher in length MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: LEROY Christophe <christophe.leroy(a)c-s.fr> commit 2b1227301a8e4729409694e323b72c064c47cb6b upstream. For SEC 2.x+, cipher in length must contain only the ciphertext length. In case of using hardware ICV checking, the ICV length is provided via the "extent" field of the descriptor pointer. Cc: <stable(a)vger.kernel.org> # 4.8+ Fixes: 549bd8bc5987 ("crypto: talitos - Implement AEAD for SEC1 using HMAC_SNOOP_NO_AFEU") Reported-by: Horia Geantă <horia.geanta(a)nxp.com> Signed-off-by: Christophe Leroy <christophe.leroy(a)c-s.fr> Tested-by: Horia Geantă <horia.geanta(a)nxp.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/crypto/talitos.c | 36 ++++++++++++++++++++---------------- 1 file changed, 20 insertions(+), 16 deletions(-) --- a/drivers/crypto/talitos.c +++ b/drivers/crypto/talitos.c @@ -1128,10 +1128,10 @@ next: return count; } -static int talitos_sg_map(struct device *dev, struct scatterlist *src, - unsigned int len, struct talitos_edesc *edesc, - struct talitos_ptr *ptr, - int sg_count, unsigned int offset, int tbl_off) +static int talitos_sg_map_ext(struct device *dev, struct scatterlist *src, + unsigned int len, struct talitos_edesc *edesc, + struct talitos_ptr *ptr, int sg_count, + unsigned int offset, int tbl_off, int elen) { struct talitos_private *priv = dev_get_drvdata(dev); bool is_sec1 = has_ftr_sec1(priv); @@ -1140,6 +1140,7 @@ static int talitos_sg_map(struct device to_talitos_ptr(ptr, 0, 0, is_sec1); return 1; } + to_talitos_ptr_ext_set(ptr, elen, is_sec1); if (sg_count == 1) { to_talitos_ptr(ptr, sg_dma_address(src) + offset, len, is_sec1); return sg_count; @@ -1148,7 +1149,7 @@ static int talitos_sg_map(struct device to_talitos_ptr(ptr, edesc->dma_link_tbl + offset, len, is_sec1); return sg_count; } - sg_count = sg_to_link_tbl_offset(src, sg_count, offset, len, + sg_count = sg_to_link_tbl_offset(src, sg_count, offset, len + elen, &edesc->link_tbl[tbl_off]); if (sg_count == 1) { /* Only one segment now, so no link tbl needed*/ @@ -1162,6 +1163,15 @@ static int talitos_sg_map(struct device return sg_count; } +static int talitos_sg_map(struct device *dev, struct scatterlist *src, + unsigned int len, struct talitos_edesc *edesc, + struct talitos_ptr *ptr, int sg_count, + unsigned int offset, int tbl_off) +{ + return talitos_sg_map_ext(dev, src, len, edesc, ptr, sg_count, offset, + tbl_off, 0); +} + /* * fill in and submit ipsec_esp descriptor */ @@ -1179,7 +1189,7 @@ static int ipsec_esp(struct talitos_edes unsigned int ivsize = crypto_aead_ivsize(aead); int tbl_off = 0; int sg_count, ret; - int sg_link_tbl_len; + int elen = 0; bool sync_needed = false; struct talitos_private *priv = dev_get_drvdata(dev); bool is_sec1 = has_ftr_sec1(priv); @@ -1221,17 +1231,11 @@ static int ipsec_esp(struct talitos_edes * extent is bytes of HMAC postpended to ciphertext, * typically 12 for ipsec */ - sg_link_tbl_len = cryptlen; - - if (is_ipsec_esp) { - to_talitos_ptr_ext_set(&desc->ptr[4], authsize, is_sec1); - - if (desc->hdr & DESC_HDR_MODE1_MDEU_CICV) - sg_link_tbl_len += authsize; - } + if (is_ipsec_esp && (desc->hdr & DESC_HDR_MODE1_MDEU_CICV)) + elen = authsize; - ret = talitos_sg_map(dev, areq->src, sg_link_tbl_len, edesc, - &desc->ptr[4], sg_count, areq->assoclen, tbl_off); + ret = talitos_sg_map_ext(dev, areq->src, cryptlen, edesc, &desc->ptr[4], + sg_count, areq->assoclen, tbl_off, elen); if (ret > 1) { tbl_off += ret; Patches currently in stable-queue which might be from christophe.leroy(a)c-s.fr are queue-4.16/crypto-talitos-fix-ipsec-cipher-in-length.patch queue-4.16/crypto-talitos-don-t-persistently-map-req_ctx-hw_context-and-req_ctx-buf.patch

7 years, 7 months

1
0
0 0

Patch "crypto: talitos - don't persistently map req_ctx->hw_context and req_ctx->buf" has been added to the 4.16-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled crypto: talitos - don't persistently map req_ctx->hw_context and req_ctx->buf to the 4.16-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: crypto-talitos-don-t-persistently-map-req_ctx-hw_context-and-req_ctx-buf.patch and it can be found in the queue-4.16 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ad4cd51fb8375109edb377712b5f9c0c31ece33e Mon Sep 17 00:00:00 2001 From: LEROY Christophe <christophe.leroy(a)c-s.fr> Date: Mon, 26 Feb 2018 17:40:04 +0100 Subject: crypto: talitos - don't persistently map req_ctx->hw_context and req_ctx->buf MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: LEROY Christophe <christophe.leroy(a)c-s.fr> commit ad4cd51fb8375109edb377712b5f9c0c31ece33e upstream. Commit 49f9783b0cea ("crypto: talitos - do hw_context DMA mapping outside the requests") introduced a persistent dma mapping of req_ctx->hw_context Commit 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash on SEC1") introduced a persistent dma mapping of req_ctx->buf As there is no destructor for req_ctx (the request context), the associated dma handlers where set in ctx (the tfm context). This is wrong as several hash operations can run with the same ctx. This patch removes this persistent mapping. Reported-by: Horia Geanta <horia.geanta(a)nxp.com> Cc: <stable(a)vger.kernel.org> Fixes: 49f9783b0cea ("crypto: talitos - do hw_context DMA mapping outside the requests") Fixes: 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash on SEC1") Signed-off-by: Christophe Leroy <christophe.leroy(a)c-s.fr> Tested-by: Horia Geantă <horia.geanta(a)nxp.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/crypto/talitos.c | 132 +++++++++++++++-------------------------------- 1 file changed, 44 insertions(+), 88 deletions(-) --- a/drivers/crypto/talitos.c +++ b/drivers/crypto/talitos.c @@ -832,8 +832,6 @@ struct talitos_ctx { unsigned int keylen; unsigned int enckeylen; unsigned int authkeylen; - dma_addr_t dma_buf; - dma_addr_t dma_hw_context; }; #define HASH_MAX_BLOCK_SIZE SHA512_BLOCK_SIZE @@ -1690,9 +1688,30 @@ static void common_nonsnoop_hash_unmap(s struct ahash_request *areq) { struct talitos_ahash_req_ctx *req_ctx = ahash_request_ctx(areq); + struct talitos_private *priv = dev_get_drvdata(dev); + bool is_sec1 = has_ftr_sec1(priv); + struct talitos_desc *desc = &edesc->desc; + struct talitos_desc *desc2 = desc + 1; + + unmap_single_talitos_ptr(dev, &edesc->desc.ptr[5], DMA_FROM_DEVICE); + if (desc->next_desc && + desc->ptr[5].ptr != desc2->ptr[5].ptr) + unmap_single_talitos_ptr(dev, &desc2->ptr[5], DMA_FROM_DEVICE); talitos_sg_unmap(dev, edesc, req_ctx->psrc, NULL, 0, 0); + /* When using hashctx-in, must unmap it. */ + if (from_talitos_ptr_len(&edesc->desc.ptr[1], is_sec1)) + unmap_single_talitos_ptr(dev, &edesc->desc.ptr[1], + DMA_TO_DEVICE); + else if (desc->next_desc) + unmap_single_talitos_ptr(dev, &desc2->ptr[1], + DMA_TO_DEVICE); + + if (is_sec1 && req_ctx->nbuf) + unmap_single_talitos_ptr(dev, &desc->ptr[3], + DMA_TO_DEVICE); + if (edesc->dma_len) dma_unmap_single(dev, edesc->dma_link_tbl, edesc->dma_len, DMA_BIDIRECTIONAL); @@ -1766,8 +1785,10 @@ static int common_nonsnoop_hash(struct t /* hash context in */ if (!req_ctx->first || req_ctx->swinit) { - to_talitos_ptr(&desc->ptr[1], ctx->dma_hw_context, - req_ctx->hw_context_size, is_sec1); + map_single_talitos_ptr(dev, &desc->ptr[1], + req_ctx->hw_context_size, + (char *)req_ctx->hw_context, + DMA_TO_DEVICE); req_ctx->swinit = 0; } /* Indicate next op is not the first. */ @@ -1793,10 +1814,9 @@ static int common_nonsnoop_hash(struct t * data in */ if (is_sec1 && req_ctx->nbuf) { - dma_addr_t dma_buf = ctx->dma_buf + req_ctx->buf_idx * - HASH_MAX_BLOCK_SIZE; - - to_talitos_ptr(&desc->ptr[3], dma_buf, req_ctx->nbuf, is_sec1); + map_single_talitos_ptr(dev, &desc->ptr[3], req_ctx->nbuf, + req_ctx->buf[req_ctx->buf_idx], + DMA_TO_DEVICE); } else { sg_count = talitos_sg_map(dev, req_ctx->psrc, length, edesc, &desc->ptr[3], sg_count, offset, 0); @@ -1812,8 +1832,9 @@ static int common_nonsnoop_hash(struct t crypto_ahash_digestsize(tfm), areq->result, DMA_FROM_DEVICE); else - to_talitos_ptr(&desc->ptr[5], ctx->dma_hw_context, - req_ctx->hw_context_size, is_sec1); + map_single_talitos_ptr(dev, &desc->ptr[5], + req_ctx->hw_context_size, + req_ctx->hw_context, DMA_FROM_DEVICE); /* last DWORD empty */ @@ -1832,9 +1853,14 @@ static int common_nonsnoop_hash(struct t desc->hdr |= DESC_HDR_MODE0_MDEU_CONT; desc->hdr &= ~DESC_HDR_DONE_NOTIFY; - to_talitos_ptr(&desc2->ptr[1], ctx->dma_hw_context, - req_ctx->hw_context_size, is_sec1); - + if (desc->ptr[1].ptr) + copy_talitos_ptr(&desc2->ptr[1], &desc->ptr[1], + is_sec1); + else + map_single_talitos_ptr(dev, &desc2->ptr[1], + req_ctx->hw_context_size, + req_ctx->hw_context, + DMA_TO_DEVICE); copy_talitos_ptr(&desc2->ptr[2], &desc->ptr[2], is_sec1); sg_count = talitos_sg_map(dev, req_ctx->psrc, length, edesc, &desc2->ptr[3], sg_count, offset, 0); @@ -1842,8 +1868,10 @@ static int common_nonsnoop_hash(struct t sync_needed = true; copy_talitos_ptr(&desc2->ptr[5], &desc->ptr[5], is_sec1); if (req_ctx->last) - to_talitos_ptr(&desc->ptr[5], ctx->dma_hw_context, - req_ctx->hw_context_size, is_sec1); + map_single_talitos_ptr(dev, &desc->ptr[5], + req_ctx->hw_context_size, + req_ctx->hw_context, + DMA_FROM_DEVICE); next_desc = dma_map_single(dev, &desc2->hdr1, TALITOS_DESC_SIZE, DMA_BIDIRECTIONAL); @@ -1881,12 +1909,8 @@ static struct talitos_edesc *ahash_edesc static int ahash_init(struct ahash_request *areq) { struct crypto_ahash *tfm = crypto_ahash_reqtfm(areq); - struct talitos_ctx *ctx = crypto_ahash_ctx(tfm); - struct device *dev = ctx->dev; struct talitos_ahash_req_ctx *req_ctx = ahash_request_ctx(areq); unsigned int size; - struct talitos_private *priv = dev_get_drvdata(dev); - bool is_sec1 = has_ftr_sec1(priv); /* Initialize the context */ req_ctx->buf_idx = 0; @@ -1898,18 +1922,6 @@ static int ahash_init(struct ahash_reque : TALITOS_MDEU_CONTEXT_SIZE_SHA384_SHA512; req_ctx->hw_context_size = size; - if (ctx->dma_hw_context) - dma_unmap_single(dev, ctx->dma_hw_context, size, - DMA_BIDIRECTIONAL); - ctx->dma_hw_context = dma_map_single(dev, req_ctx->hw_context, size, - DMA_BIDIRECTIONAL); - if (ctx->dma_buf) - dma_unmap_single(dev, ctx->dma_buf, sizeof(req_ctx->buf), - DMA_TO_DEVICE); - if (is_sec1) - ctx->dma_buf = dma_map_single(dev, req_ctx->buf, - sizeof(req_ctx->buf), - DMA_TO_DEVICE); return 0; } @@ -1920,9 +1932,6 @@ static int ahash_init(struct ahash_reque static int ahash_init_sha224_swinit(struct ahash_request *areq) { struct talitos_ahash_req_ctx *req_ctx = ahash_request_ctx(areq); - struct crypto_ahash *tfm = crypto_ahash_reqtfm(areq); - struct talitos_ctx *ctx = crypto_ahash_ctx(tfm); - struct device *dev = ctx->dev; ahash_init(areq); req_ctx->swinit = 1;/* prevent h/w initting context with sha256 values*/ @@ -1940,9 +1949,6 @@ static int ahash_init_sha224_swinit(stru req_ctx->hw_context[8] = 0; req_ctx->hw_context[9] = 0; - dma_sync_single_for_device(dev, ctx->dma_hw_context, - req_ctx->hw_context_size, DMA_TO_DEVICE); - return 0; } @@ -2046,13 +2052,6 @@ static int ahash_process_req(struct ahas /* request SEC to INIT hash. */ if (req_ctx->first && !req_ctx->swinit) edesc->desc.hdr |= DESC_HDR_MODE0_MDEU_INIT; - if (is_sec1) { - dma_addr_t dma_buf = ctx->dma_buf + req_ctx->buf_idx * - HASH_MAX_BLOCK_SIZE; - - dma_sync_single_for_device(dev, dma_buf, - req_ctx->nbuf, DMA_TO_DEVICE); - } /* When the tfm context has a keylen, it's an HMAC. * A first or last (ie. not middle) descriptor must request HMAC. @@ -2106,12 +2105,7 @@ static int ahash_export(struct ahash_req { struct talitos_ahash_req_ctx *req_ctx = ahash_request_ctx(areq); struct talitos_export_state *export = out; - struct crypto_ahash *ahash = crypto_ahash_reqtfm(areq); - struct talitos_ctx *ctx = crypto_ahash_ctx(ahash); - struct device *dev = ctx->dev; - dma_sync_single_for_cpu(dev, ctx->dma_hw_context, - req_ctx->hw_context_size, DMA_FROM_DEVICE); memcpy(export->hw_context, req_ctx->hw_context, req_ctx->hw_context_size); memcpy(export->buf, req_ctx->buf[req_ctx->buf_idx], req_ctx->nbuf); @@ -2130,31 +2124,14 @@ static int ahash_import(struct ahash_req struct crypto_ahash *tfm = crypto_ahash_reqtfm(areq); const struct talitos_export_state *export = in; unsigned int size; - struct talitos_ctx *ctx = crypto_ahash_ctx(tfm); - struct device *dev = ctx->dev; - struct talitos_private *priv = dev_get_drvdata(dev); - bool is_sec1 = has_ftr_sec1(priv); memset(req_ctx, 0, sizeof(*req_ctx)); size = (crypto_ahash_digestsize(tfm) <= SHA256_DIGEST_SIZE) ? TALITOS_MDEU_CONTEXT_SIZE_MD5_SHA1_SHA256 : TALITOS_MDEU_CONTEXT_SIZE_SHA384_SHA512; req_ctx->hw_context_size = size; - if (ctx->dma_hw_context) - dma_unmap_single(dev, ctx->dma_hw_context, size, - DMA_BIDIRECTIONAL); - memcpy(req_ctx->hw_context, export->hw_context, size); - ctx->dma_hw_context = dma_map_single(dev, req_ctx->hw_context, size, - DMA_BIDIRECTIONAL); - if (ctx->dma_buf) - dma_unmap_single(dev, ctx->dma_buf, sizeof(req_ctx->buf), - DMA_TO_DEVICE); memcpy(req_ctx->buf[0], export->buf, export->nbuf); - if (is_sec1) - ctx->dma_buf = dma_map_single(dev, req_ctx->buf, - sizeof(req_ctx->buf), - DMA_TO_DEVICE); req_ctx->swinit = export->swinit; req_ctx->first = export->first; req_ctx->last = export->last; @@ -3064,27 +3041,6 @@ static void talitos_cra_exit(struct cryp dma_unmap_single(dev, ctx->dma_key, ctx->keylen, DMA_TO_DEVICE); } -static void talitos_cra_exit_ahash(struct crypto_tfm *tfm) -{ - struct talitos_ctx *ctx = crypto_tfm_ctx(tfm); - struct device *dev = ctx->dev; - unsigned int size; - - talitos_cra_exit(tfm); - - size = (crypto_ahash_digestsize(__crypto_ahash_cast(tfm)) <= - SHA256_DIGEST_SIZE) - ? TALITOS_MDEU_CONTEXT_SIZE_MD5_SHA1_SHA256 - : TALITOS_MDEU_CONTEXT_SIZE_SHA384_SHA512; - - if (ctx->dma_hw_context) - dma_unmap_single(dev, ctx->dma_hw_context, size, - DMA_BIDIRECTIONAL); - if (ctx->dma_buf) - dma_unmap_single(dev, ctx->dma_buf, HASH_MAX_BLOCK_SIZE * 2, - DMA_TO_DEVICE); -} - /* * given the alg's descriptor header template, determine whether descriptor * type and primary/secondary execution units required match the hw @@ -3183,7 +3139,7 @@ static struct talitos_crypto_alg *talito case CRYPTO_ALG_TYPE_AHASH: alg = &t_alg->algt.alg.hash.halg.base; alg->cra_init = talitos_cra_init_ahash; - alg->cra_exit = talitos_cra_exit_ahash; + alg->cra_exit = talitos_cra_exit; alg->cra_type = &crypto_ahash_type; t_alg->algt.alg.hash.init = ahash_init; t_alg->algt.alg.hash.update = ahash_update; Patches currently in stable-queue which might be from christophe.leroy(a)c-s.fr are queue-4.16/crypto-talitos-fix-ipsec-cipher-in-length.patch queue-4.16/crypto-talitos-don-t-persistently-map-req_ctx-hw_context-and-req_ctx-buf.patch

7 years, 7 months

1
0
0 0

Patch "crypto: lrw - Free rctx->ext with kzfree" has been added to the 4.16-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled crypto: lrw - Free rctx->ext with kzfree to the 4.16-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: crypto-lrw-free-rctx-ext-with-kzfree.patch and it can be found in the queue-4.16 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 8c9bdab21289c211ca1ca6a5f9b7537b4a600a02 Mon Sep 17 00:00:00 2001 From: Herbert Xu <herbert(a)gondor.apana.org.au> Date: Fri, 23 Mar 2018 08:14:44 +0800 Subject: crypto: lrw - Free rctx->ext with kzfree From: Herbert Xu <herbert(a)gondor.apana.org.au> commit 8c9bdab21289c211ca1ca6a5f9b7537b4a600a02 upstream. The buffer rctx->ext contains potentially sensitive data and should be freed with kzfree. Cc: <stable(a)vger.kernel.org> Fixes: 700cb3f5fe75 ("crypto: lrw - Convert to skcipher") Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- crypto/lrw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/crypto/lrw.c +++ b/crypto/lrw.c @@ -313,7 +313,7 @@ static void exit_crypt(struct skcipher_r rctx->left = 0; if (rctx->ext) - kfree(rctx->ext); + kzfree(rctx->ext); } static int do_encrypt(struct skcipher_request *req, int err) Patches currently in stable-queue which might be from herbert(a)gondor.apana.org.au are queue-4.16/crypto-caam-fix-null-dereference-at-error-path.patch queue-4.16/crypto-ccp-fill-the-result-buffer-only-on-digest-finup-and-final-ops.patch queue-4.16/crypto-talitos-fix-ipsec-cipher-in-length.patch queue-4.16/crypto-x86-cast5-avx-fix-ecb-encryption-when-long-sg-follows-short-one.patch queue-4.16/crypto-arm-arm64-fix-random-regeneration-of-s_shipped.patch queue-4.16/crypto-ccp-return-an-actual-key-size-from-rsa-max_size-callback.patch queue-4.16/crypto-inside-secure-fix-clock-management.patch queue-4.16/crypto-lrw-free-rctx-ext-with-kzfree.patch queue-4.16/crypto-testmgr-fix-incorrect-values-in-pkcs-1-test-vector.patch queue-4.16/crypto-talitos-don-t-persistently-map-req_ctx-hw_context-and-req_ctx-buf.patch queue-4.16/crypto-ahash-fix-early-termination-in-hash-walk.patch

7 years, 7 months

1
0
0 0

Patch "crypto: inside-secure - fix clock management" has been added to the 4.16-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled crypto: inside-secure - fix clock management to the 4.16-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: crypto-inside-secure-fix-clock-management.patch and it can be found in the queue-4.16 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From f962eb46e7a9b98a58d2483f5eb216e738fec732 Mon Sep 17 00:00:00 2001 From: Gregory CLEMENT <gregory.clement(a)bootlin.com> Date: Tue, 13 Mar 2018 17:48:40 +0100 Subject: crypto: inside-secure - fix clock management From: Gregory CLEMENT <gregory.clement(a)bootlin.com> commit f962eb46e7a9b98a58d2483f5eb216e738fec732 upstream. In this driver the clock is got but never put when the driver is removed or if there is an error in the probe. Using the managed version of clk_get() allows to let the kernel take care of it. Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto engine driver") cc: stable(a)vger.kernel.org Signed-off-by: Gregory CLEMENT <gregory.clement(a)bootlin.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/crypto/inside-secure/safexcel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/crypto/inside-secure/safexcel.c +++ b/drivers/crypto/inside-secure/safexcel.c @@ -894,7 +894,7 @@ static int safexcel_probe(struct platfor return PTR_ERR(priv->base); } - priv->clk = of_clk_get(dev->of_node, 0); + priv->clk = devm_clk_get(&pdev->dev, NULL); if (!IS_ERR(priv->clk)) { ret = clk_prepare_enable(priv->clk); if (ret) { Patches currently in stable-queue which might be from gregory.clement(a)bootlin.com are queue-4.16/crypto-inside-secure-fix-clock-management.patch

7 years, 7 months

1
0
0 0

Patch "crypto: ccp - return an actual key size from RSA max_size callback" has been added to the 4.16-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled crypto: ccp - return an actual key size from RSA max_size callback to the 4.16-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: crypto-ccp-return-an-actual-key-size-from-rsa-max_size-callback.patch and it can be found in the queue-4.16 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 0a9eb80e643064266868bd2fb2cd608e669309b0 Mon Sep 17 00:00:00 2001 From: "Maciej S. Szmigiero" <mail(a)maciej.szmigiero.name> Date: Sat, 24 Feb 2018 17:03:21 +0100 Subject: crypto: ccp - return an actual key size from RSA max_size callback From: Maciej S. Szmigiero <mail(a)maciej.szmigiero.name> commit 0a9eb80e643064266868bd2fb2cd608e669309b0 upstream. rsa-pkcs1pad uses a value returned from a RSA implementation max_size callback as a size of an input buffer passed to the RSA implementation for encrypt and sign operations. CCP RSA implementation uses a hardware input buffer which size depends only on the current RSA key length, so it should return this key length in the max_size callback, too. This also matches what the kernel software RSA implementation does. Previously, the value returned from this callback was always the maximum RSA key size the CCP hardware supports. This resulted in this huge buffer being passed by rsa-pkcs1pad to CCP even for smaller key sizes and then in a buffer overflow when ccp_run_rsa_cmd() tried to copy this large input buffer into a RSA key length-sized hardware input buffer. Signed-off-by: Maciej S. Szmigiero <mail(a)maciej.szmigiero.name> Fixes: ceeec0afd684 ("crypto: ccp - Add support for RSA on the CCP") Cc: stable(a)vger.kernel.org Acked-by: Gary R Hook <gary.hook(a)amd.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/crypto/ccp/ccp-crypto-rsa.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) --- a/drivers/crypto/ccp/ccp-crypto-rsa.c +++ b/drivers/crypto/ccp/ccp-crypto-rsa.c @@ -60,10 +60,9 @@ static int ccp_rsa_complete(struct crypt static unsigned int ccp_rsa_maxsize(struct crypto_akcipher *tfm) { - if (ccp_version() > CCP_VERSION(3, 0)) - return CCP5_RSA_MAXMOD; - else - return CCP_RSA_MAXMOD; + struct ccp_ctx *ctx = akcipher_tfm_ctx(tfm); + + return ctx->u.rsa.n_len; } static int ccp_rsa_crypt(struct akcipher_request *req, bool encrypt) Patches currently in stable-queue which might be from mail(a)maciej.szmigiero.name are queue-4.16/crypto-ccp-return-an-actual-key-size-from-rsa-max_size-callback.patch

7 years, 7 months

1
0
0 0

Patch "crypto: ccp - Fill the result buffer only on digest, finup, and final ops" has been added to the 4.16-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled crypto: ccp - Fill the result buffer only on digest, finup, and final ops to the 4.16-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: crypto-ccp-fill-the-result-buffer-only-on-digest-finup-and-final-ops.patch and it can be found in the queue-4.16 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 0ee991be4cdd88587aedbf68cdacd1765f57236a Mon Sep 17 00:00:00 2001 From: Gary R Hook <gary.hook(a)amd.com> Date: Wed, 7 Mar 2018 11:37:42 -0600 Subject: crypto: ccp - Fill the result buffer only on digest, finup, and final ops From: Gary R Hook <gary.hook(a)amd.com> commit 0ee991be4cdd88587aedbf68cdacd1765f57236a upstream. Any change to the result buffer should only happen on final, finup and digest operations. Changes to the buffer for update, import, export, etc, are not allowed. Fixes: 66d7b9f6175e ("crypto: testmgr - test misuse of result in ahash") Signed-off-by: Gary R Hook <gary.hook(a)amd.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/crypto/ccp/ccp-crypto-aes-cmac.c | 2 +- drivers/crypto/ccp/ccp-crypto-sha.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) --- a/drivers/crypto/ccp/ccp-crypto-aes-cmac.c +++ b/drivers/crypto/ccp/ccp-crypto-aes-cmac.c @@ -46,7 +46,7 @@ static int ccp_aes_cmac_complete(struct } /* Update result area if supplied */ - if (req->result) + if (req->result && rctx->final) memcpy(req->result, rctx->iv, digest_size); e_free: --- a/drivers/crypto/ccp/ccp-crypto-sha.c +++ b/drivers/crypto/ccp/ccp-crypto-sha.c @@ -47,7 +47,7 @@ static int ccp_sha_complete(struct crypt } /* Update result area if supplied */ - if (req->result) + if (req->result && rctx->final) memcpy(req->result, rctx->ctx, digest_size); e_free: Patches currently in stable-queue which might be from gary.hook(a)amd.com are queue-4.16/crypto-ccp-fill-the-result-buffer-only-on-digest-finup-and-final-ops.patch queue-4.16/crypto-ccp-return-an-actual-key-size-from-rsa-max_size-callback.patch

7 years, 7 months

1
0
0 0

Patch "crypto: caam - Fix null dereference at error path" has been added to the 4.16-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled crypto: caam - Fix null dereference at error path to the 4.16-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: crypto-caam-fix-null-dereference-at-error-path.patch and it can be found in the queue-4.16 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From b85149f6f5d5a9279f29a73b2e95342f4d465e73 Mon Sep 17 00:00:00 2001 From: Rui Miguel Silva <rui.silva(a)linaro.org> Date: Thu, 22 Feb 2018 14:22:47 +0000 Subject: crypto: caam - Fix null dereference at error path MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Rui Miguel Silva <rui.silva(a)linaro.org> commit b85149f6f5d5a9279f29a73b2e95342f4d465e73 upstream. caam_remove already removes the debugfs entry, so we need to remove the one immediately before calling caam_remove. This fix a NULL dereference at error paths is caam_probe fail. Fixes: 67c2315def06 ("crypto: caam - add Queue Interface (QI) backend support") Tested-by: Ryan Harkin <ryan.harkin(a)linaro.org> Cc: "Horia Geantă" <horia.geanta(a)nxp.com> Cc: Aymen Sghaier <aymen.sghaier(a)nxp.com> Cc: Fabio Estevam <fabio.estevam(a)nxp.com> Cc: Peng Fan <peng.fan(a)nxp.com> Cc: "David S. Miller" <davem(a)davemloft.net> Cc: Lukas Auer <lukas.auer(a)aisec.fraunhofer.de> Cc: <stable(a)vger.kernel.org> # 4.12+ Reviewed-by: Horia Geantă <horia.geanta(a)nxp.com> Signed-off-by: Rui Miguel Silva <rui.silva(a)linaro.org> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/crypto/caam/ctrl.c | 3 --- 1 file changed, 3 deletions(-) --- a/drivers/crypto/caam/ctrl.c +++ b/drivers/crypto/caam/ctrl.c @@ -815,9 +815,6 @@ static int caam_probe(struct platform_de return 0; caam_remove: -#ifdef CONFIG_DEBUG_FS - debugfs_remove_recursive(ctrlpriv->dfs_root); -#endif caam_remove(pdev); return ret; Patches currently in stable-queue which might be from rui.silva(a)linaro.org are queue-4.16/crypto-caam-fix-null-dereference-at-error-path.patch

7 years, 7 months

1
0
0 0

Patch "crypto: arm, arm64 - Fix random regeneration of S_shipped" has been added to the 4.16-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled crypto: arm,arm64 - Fix random regeneration of S_shipped to the 4.16-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: crypto-arm-arm64-fix-random-regeneration-of-s_shipped.patch and it can be found in the queue-4.16 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 6aaf49b495b446ff6eec0ac983f781ca0dc56a73 Mon Sep 17 00:00:00 2001 From: Leonard Crestez <leonard.crestez(a)nxp.com> Date: Tue, 13 Mar 2018 22:17:23 +0200 Subject: crypto: arm,arm64 - Fix random regeneration of S_shipped From: Leonard Crestez <leonard.crestez(a)nxp.com> commit 6aaf49b495b446ff6eec0ac983f781ca0dc56a73 upstream. The decision to rebuild .S_shipped is made based on the relative timestamps of .S_shipped and .pl files but git makes this essentially random. This means that the perl script might run anyway (usually at most once per checkout), defeating the whole purpose of _shipped. Fix by skipping the rule unless explicit make variables are provided: REGENERATE_ARM_CRYPTO or REGENERATE_ARM64_CRYPTO. This can produce nasty occasional build failures downstream, for example for toolchains with broken perl. The solution is minimally intrusive to make it easier to push into stable. Another report on a similar issue here: https://lkml.org/lkml/2018/3/8/1379 Signed-off-by: Leonard Crestez <leonard.crestez(a)nxp.com> Cc: <stable(a)vger.kernel.org> Reviewed-by: Masahiro Yamada <yamada.masahiro(a)socionext.com> Acked-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/crypto/Makefile | 2 ++ arch/arm64/crypto/Makefile | 2 ++ 2 files changed, 4 insertions(+) --- a/arch/arm/crypto/Makefile +++ b/arch/arm/crypto/Makefile @@ -54,6 +54,7 @@ crct10dif-arm-ce-y := crct10dif-ce-core. crc32-arm-ce-y:= crc32-ce-core.o crc32-ce-glue.o chacha20-neon-y := chacha20-neon-core.o chacha20-neon-glue.o +ifdef REGENERATE_ARM_CRYPTO quiet_cmd_perl = PERL $@ cmd_perl = $(PERL) $(<) > $(@) @@ -62,5 +63,6 @@ $(src)/sha256-core.S_shipped: $(src)/sha $(src)/sha512-core.S_shipped: $(src)/sha512-armv4.pl $(call cmd,perl) +endif .PRECIOUS: $(obj)/sha256-core.S $(obj)/sha512-core.S --- a/arch/arm64/crypto/Makefile +++ b/arch/arm64/crypto/Makefile @@ -67,6 +67,7 @@ CFLAGS_aes-glue-ce.o := -DUSE_V8_CRYPTO_ $(obj)/aes-glue-%.o: $(src)/aes-glue.c FORCE $(call if_changed_rule,cc_o_c) +ifdef REGENERATE_ARM64_CRYPTO quiet_cmd_perlasm = PERLASM $@ cmd_perlasm = $(PERL) $(<) void $(@) @@ -75,5 +76,6 @@ $(src)/sha256-core.S_shipped: $(src)/sha $(src)/sha512-core.S_shipped: $(src)/sha512-armv8.pl $(call cmd,perlasm) +endif .PRECIOUS: $(obj)/sha256-core.S $(obj)/sha512-core.S Patches currently in stable-queue which might be from leonard.crestez(a)nxp.com are queue-4.16/crypto-arm-arm64-fix-random-regeneration-of-s_shipped.patch

7 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror