kernel/drivers/crypto, branch linux-5.1.y

crypto: crypto4xx - fix a potential double free in ppc4xx_trng_probe

2019-07-26T07:12:54Z

commit 95566aa75cd6b3b404502c06f66956b5481194b3 upstream. There is a possible double free issue in ppc4xx_trng_probe(): 85: dev->trng_base = of_iomap(trng, 0); 86: of_node_put(trng); ---> released here 87: if (!dev->trng_base) 88: goto err_out; ... 110: ierr_out: 111: of_node_put(trng); ---> double released here ... This issue was detected by using the Coccinelle software. We fix it by removing the unnecessary of_node_put(). Fixes: 5343e674f32f ("crypto4xx: integrate ppc4xx-rng into crypto4xx") Signed-off-by: Wen Yang Cc: Cc: "David S. Miller" Cc: Thomas Gleixner Cc: Greg Kroah-Hartman Cc: Allison Randal Cc: Armijn Hemel Cc: Julia Lawall Cc: linux-crypto@vger.kernel.org Cc: linux-kernel@vger.kernel.org Acked-by: Julia Lawall Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: ccp/gcm - use const time tag comparison.

2019-07-26T07:12:54Z

commit 538a5a072e6ef04377b180ee9b3ce5bae0a85da4 upstream. Avoid leaking GCM tag through timing side channel. Fixes: 36cf515b9bbe ("crypto: ccp - Enable support for AES GCM on v5 CCPs") Cc: # v4.12+ Signed-off-by: Cfir Cohen Acked-by: Gary R Hook Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: ccp - memset structure fields to zero before reuse

2019-07-26T07:12:54Z

commit 20e833dc36355ed642d00067641a679c618303fa upstream. The AES GCM function reuses an 'op' data structure, which members contain values that must be cleared for each (re)use. This fix resolves a crypto self-test failure: alg: aead: gcm-aes-ccp encryption test failed (wrong result) on test vector 2, cfg="two even aligned splits" Fixes: 36cf515b9bbe ("crypto: ccp - Enable support for AES GCM on v5 CCPs") Cc: Signed-off-by: Gary R Hook Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: crypto4xx - block ciphers should only accept complete blocks

2019-07-26T07:12:53Z

commit 0f7a81374060828280fcfdfbaa162cb559017f9f upstream. The hardware automatically zero pads incomplete block ciphers blocks without raising any errors. This is a screw-up. This was noticed by CONFIG_CRYPTO_MANAGER_EXTRA_TESTS tests that sent a incomplete blocks and expect them to fail. This fixes: cbc-aes-ppc4xx encryption unexpectedly succeeded on test vector "random: len=2409 klen=32"; expected_error=-22, cfg="random: may_sleep use_digest src_divs=[96.90%@+2295, 2.34%@+4066, 0.32%@alignmask+12, 0.34%@+4087, 0.9%@alignmask+1787, 0.1%@+3767] iv_offset=6" ecb-aes-ppc4xx encryption unexpectedly succeeded on test vector "random: len=1011 klen=32"; expected_error=-22, cfg="random: may_sleep use_digest src_divs=[100.0%@alignmask+20] dst_divs=[3.12%@+3001, 96.88%@+4070]" Cc: Eric Biggers Cc: stable@vger.kernel.org [4.19, 5.0 and 5.1] Signed-off-by: Christian Lamparter Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: crypto4xx - fix blocksize for cfb and ofb

2019-07-26T07:12:53Z

commit 70c4997f34b6c6888b3ac157adec49e01d0df2d5 upstream. While the hardware consider them to be blockciphers, the reference implementation defines them as streamciphers. Do the right thing and set the blocksize to 1. This was found by CONFIG_CRYPTO_MANAGER_EXTRA_TESTS. This fixes the following issues: skcipher: blocksize for ofb-aes-ppc4xx (16) doesn't match generic impl (1) skcipher: blocksize for cfb-aes-ppc4xx (16) doesn't match generic impl (1) Cc: Eric Biggers Cc: stable@vger.kernel.org Fixes: f2a13e7cba9e ("crypto: crypto4xx - enable AES RFC3686, ECB, CFB and OFB offloads") Signed-off-by: Christian Lamparter Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: crypto4xx - fix AES CTR blocksize value

2019-07-26T07:12:53Z

commit bfa2ba7d9e6b20aca82b99e6842fe18842ae3a0f upstream. This patch fixes a issue with crypto4xx's ctr(aes) that was discovered by libcapi's kcapi-enc-test.sh test. The some of the ctr(aes) encryptions test were failing on the non-power-of-two test: kcapi-enc - Error: encryption failed with error 0 kcapi-enc - Error: decryption failed with error 0 [FAILED: 32-bit - 5.1.0-rc1+] 15 bytes: STDIN / STDOUT enc test (128 bits): original file (1d100e..cc96184c) and generated file (e3b0c442..1b7852b855) [FAILED: 32-bit - 5.1.0-rc1+] 15 bytes: STDIN / STDOUT enc test (128 bits) (openssl generated CT): original file (e3b0..5) and generated file (3..8e) [PASSED: 32-bit - 5.1.0-rc1+] 15 bytes: STDIN / STDOUT enc test (128 bits) (openssl generated PT) [FAILED: 32-bit - 5.1.0-rc1+] 15 bytes: STDIN / STDOUT enc test (password): original file (1d1..84c) and generated file (e3b..852b855) But the 16, 32, 512, 65536 tests always worked. Thankfully, this isn't a hidden hardware problem like previously, instead this turned out to be a copy and paste issue. With this patch, all the tests are passing with and kcapi-enc-test.sh gives crypto4xx's a clean bill of health: "Number of failures: 0" :). Cc: stable@vger.kernel.org Fixes: 98e87e3d933b ("crypto: crypto4xx - add aes-ctr support") Fixes: f2a13e7cba9e ("crypto: crypto4xx - enable AES RFC3686, ECB, CFB and OFB offloads") Signed-off-by: Christian Lamparter Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: ccp - Validate the the error value used to index error messages

2019-07-26T07:12:53Z

commit 52393d617af7b554f03531e6756facf2ea687d2e upstream. The error code read from the queue status register is only 6 bits wide, but we need to verify its value is within range before indexing the error messages. Fixes: 81422badb3907 ("crypto: ccp - Make syslog errors human-readable") Cc: Reported-by: Cfir Cohen Signed-off-by: Gary R Hook Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: caam - limit output IV to CBC to work around CTR mode DMA issue

2019-07-26T07:12:53Z

commit ed527b13d800dd515a9e6c582f0a73eca65b2e1b upstream. The CAAM driver currently violates an undocumented and slightly controversial requirement imposed by the crypto stack that a buffer referred to by the request structure via its virtual address may not be modified while any scatterlists passed via the same request structure are mapped for inbound DMA. This may result in errors like alg: aead: decryption failed on test 1 for gcm_base(ctr-aes-caam,ghash-generic): ret=74 alg: aead: Failed to load transform for gcm(aes): -2 on non-cache coherent systems, due to the fact that the GCM driver passes an IV buffer by virtual address which shares a cacheline with the auth_tag buffer passed via a scatterlist, resulting in corruption of the auth_tag when the IV is updated while the DMA mapping is live. Since the IV that is returned to the caller is only valid for CBC mode, and given that the in-kernel users of CBC (such as CTS) don't trigger the same issue as the GCM driver, let's just disable the output IV generation for all modes except CBC for the time being. Fixes: 854b06f76879 ("crypto: caam - properly set IV after {en,de}crypt") Cc: Horia Geanta Cc: Iuliana Prodan Reported-by: Sascha Hauer Cc: Signed-off-by: Ard Biesheuvel Reviewed-by: Horia Geanta Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: inside-secure - do not rely on the hardware last bit for result descriptors

2019-07-26T07:12:31Z

[ Upstream commit 89332590427235680236b9470e851afc49b3caa1 ] When performing a transformation the hardware is given result descriptors to save the result data. Those result descriptors are batched using a 'first' and a 'last' bit. There are cases were more descriptors than needed are given to the engine, leading to the engine only using some of them, and not setting the last bit on the last descriptor we gave. This causes issues were the driver and the hardware aren't in sync anymore about the number of result descriptors given (as the driver do not give a pool of descriptor to use for any transformation, but a pool of descriptors to use *per* transformation). This patch fixes it by attaching the number of given result descriptors to the requests, and by using this number instead of the 'last' bit found on the descriptors to process them. Signed-off-by: Antoine Tenart Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

crypto: talitos - Align SEC1 accesses to 32 bits boundaries.

2019-07-26T07:12:28Z

[ Upstream commit c9cca7034b34a2d82e9a03b757de2485c294851c ] The MPC885 reference manual states: SEC Lite-initiated 8xx writes can occur only on 32-bit-word boundaries, but reads can occur on any byte boundary. Writing back a header read from a non-32-bit-word boundary will yield unpredictable results. In order to ensure that, cra_alignmask is set to 3 for SEC1. Signed-off-by: Christophe Leroy Fixes: 9c4a79653b35 ("crypto: talitos - Freescale integrated security engine (SEC) driver") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin