user/sven/linux.git/drivers/crypto, branch v4.19.92

crypto: vmx - Avoid weird build failures

2019-12-31T15:36:13Z

[ Upstream commit 4ee812f6143d78d8ba1399671d78c8d78bf2817c ] In the vmx crypto Makefile we assign to a variable called TARGET and pass that to the aesp8-ppc.pl and ghashp8-ppc.pl scripts. The variable is meant to describe what flavour of powerpc we're building for, eg. either 32 or 64-bit, and big or little endian. Unfortunately TARGET is a fairly common name for a make variable, and if it happens that TARGET is specified as a command line parameter to make, the value specified on the command line will override our value. In particular this can happen if the kernel Makefile is driven by an external Makefile that uses TARGET for something. This leads to weird build failures, eg: nonsense at /build/linux/drivers/crypto/vmx/ghashp8-ppc.pl line 45. /linux/drivers/crypto/vmx/Makefile:20: recipe for target 'drivers/crypto/vmx/ghashp8-ppc.S' failed Which shows that we passed an empty value for $(TARGET) to the perl script, confirmed with make V=1: perl /linux/drivers/crypto/vmx/ghashp8-ppc.pl > drivers/crypto/vmx/ghashp8-ppc.S We can avoid this confusion by using override, to tell make that we don't want anything to override our variable, even a value specified on the command line. We can also use a less common name, given the script calls it "flavour", let's use that. Signed-off-by: Michael Ellerman Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

crypto: sun4i-ss - Fix 64-bit size_t warnings on sun4i-ss-hash.c

2019-12-31T15:36:12Z

[ Upstream commit a7126603d46fe8f01aeedf589e071c6aaa6c6c39 ] If you try to compile this driver on a 64-bit platform then you will get warnings because it mixes size_t with unsigned int which only works on 32-bit. This patch fixes all of the warnings on sun4i-ss-hash.c. Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

crypto: sun4i-ss - Fix 64-bit size_t warnings

2019-12-31T15:36:12Z

[ Upstream commit d6e9da21ee8246b5e556b3b153401ab045adb986 ] If you try to compile this driver on a 64-bit platform then you will get warnings because it mixes size_t with unsigned int which only works on 32-bit. This patch fixes all of the warnings. Signed-off-by: Herbert Xu Acked-by: Corentin Labbe Tested-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

crypto: virtio - deal with unsupported input sizes

2019-12-31T15:36:04Z

[ Upstream commit 19c5da7d4a2662e85ea67d2d81df57e038fde3ab ] Return -EINVAL for input sizes that are not a multiple of the AES block size, since they are not supported by our CBC chaining mode. While at it, remove the pr_err() that reports unsupported key sizes being used: we shouldn't spam the kernel log with that. Fixes: dbaf0624ffa5 ("crypto: add virtio-crypto driver") Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Gonglei Cc: virtualization@lists.linux-foundation.org Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

crypto: atmel - Fix authenc support when it is set to m

2019-12-31T15:35:56Z

[ Upstream commit 1520c72596dde7f22b8bd6bed3ef7df2b8b7ef39 ] As it is if CONFIG_CRYPTO_DEV_ATMEL_AUTHENC is set to m it is in effect disabled. This patch fixes it by using IS_ENABLED instead of ifdef. Fixes: 89a82ef87e01 ("crypto: atmel-authenc - add support to...") Signed-off-by: Herbert Xu Reviewed-by: Tudor Ambarus Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

crypto: ccp - fix uninitialized list head

2019-12-13T07:52:47Z

commit 691505a803a7f223b2af621848d581259c61f77d upstream. A NULL-pointer dereference was reported in fedora bz#1762199 while reshaping a raid6 array after adding a fifth drive to an existing array. [ 47.343549] md/raid:md0: raid level 6 active with 3 out of 5 devices, algorithm 2 [ 47.804017] md0: detected capacity change from 0 to 7885289422848 [ 47.822083] Unable to handle kernel read from unreadable memory at virtual address 0000000000000000 ... [ 47.940477] CPU: 1 PID: 14210 Comm: md0_raid6 Tainted: G W 5.2.18-200.fc30.aarch64 #1 [ 47.949594] Hardware name: AMD Overdrive/Supercharger/To be filled by O.E.M., BIOS ROD1002C 04/08/2016 [ 47.958886] pstate: 00400085 (nzcv daIf +PAN -UAO) [ 47.963668] pc : __list_del_entry_valid+0x2c/0xa8 [ 47.968366] lr : ccp_tx_submit+0x84/0x168 [ccp] [ 47.972882] sp : ffff00001369b970 [ 47.976184] x29: ffff00001369b970 x28: ffff00001369bdb8 [ 47.981483] x27: 00000000ffffffff x26: ffff8003b758af70 [ 47.986782] x25: ffff8003b758b2d8 x24: ffff8003e6245818 [ 47.992080] x23: 0000000000000000 x22: ffff8003e62450c0 [ 47.997379] x21: ffff8003dfd6add8 x20: 0000000000000003 [ 48.002678] x19: ffff8003e6245100 x18: 0000000000000000 [ 48.007976] x17: 0000000000000000 x16: 0000000000000000 [ 48.013274] x15: 0000000000000000 x14: 0000000000000000 [ 48.018572] x13: ffff7e000ef83a00 x12: 0000000000000001 [ 48.023870] x11: ffff000010eff998 x10: 00000000000019a0 [ 48.029169] x9 : 0000000000000000 x8 : ffff8003e6245180 [ 48.034467] x7 : 0000000000000000 x6 : 000000000000003f [ 48.039766] x5 : 0000000000000040 x4 : ffff8003e0145080 [ 48.045064] x3 : dead000000000200 x2 : 0000000000000000 [ 48.050362] x1 : 0000000000000000 x0 : ffff8003e62450c0 [ 48.055660] Call trace: [ 48.058095] __list_del_entry_valid+0x2c/0xa8 [ 48.062442] ccp_tx_submit+0x84/0x168 [ccp] [ 48.066615] async_tx_submit+0x224/0x368 [async_tx] [ 48.071480] async_trigger_callback+0x68/0xfc [async_tx] [ 48.076784] ops_run_biofill+0x178/0x1e8 [raid456] [ 48.081566] raid_run_ops+0x248/0x818 [raid456] [ 48.086086] handle_stripe+0x864/0x1208 [raid456] [ 48.090781] handle_active_stripes.isra.0+0xb0/0x278 [raid456] [ 48.096604] raid5d+0x378/0x618 [raid456] [ 48.100602] md_thread+0xa0/0x150 [ 48.103905] kthread+0x104/0x130 [ 48.107122] ret_from_fork+0x10/0x18 [ 48.110686] Code: d2804003 f2fbd5a3 eb03003f 54000320 (f9400021) [ 48.116766] ---[ end trace 23f390a527f7ad77 ]--- ccp_tx_submit is passed a dma_async_tx_descriptor which is contained in a ccp_dma_desc and adds it to a ccp channel's pending list: list_del(&desc->entry); list_add_tail(&desc->entry, &chan->pending); The problem is that desc->entry may be uninitialized in the async_trigger_callback path where the descriptor was gotten from ccp_prep_dma_interrupt which got it from ccp_alloc_dma_desc which doesn't initialize the desc->entry list head. So, just initialize the list head to avoid the problem. Cc: Reported-by: Sahaj Sarup Signed-off-by: Mark Salter Acked-by: Gary R Hook Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: atmel-aes - Fix IV handling when req->nbytes < ivsize

2019-12-13T07:52:46Z

commit 86ef1dfcb561473fbf5e199d58d18c55554d78be upstream. commit 394a9e044702 ("crypto: cfb - add missing 'chunksize' property") adds a test vector where the input length is smaller than the IV length (the second test vector). This revealed a NULL pointer dereference in the atmel-aes driver, that is caused by passing an incorrect offset in scatterwalk_map_and_copy() when atmel_aes_complete() is called. Do not save the IV in req->info of ablkcipher_request (or equivalently req->iv of skcipher_request) when req->nbytes < ivsize, because the IV will not be further used. While touching the code, modify the type of ivsize from int to unsigned int, to comply with the return type of crypto_ablkcipher_ivsize(). Fixes: 91308019ecb4 ("crypto: atmel-aes - properly set IV after {en,de}crypt") Cc: Signed-off-by: Tudor Ambarus Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: crypto4xx - fix double-free in crypto4xx_destroy_sdr

2019-12-13T07:52:46Z

commit 746c908c4d72e49068ab216c3926d2720d71a90d upstream. This patch fixes a crash that can happen during probe when the available dma memory is not enough (this can happen if the crypto4xx is built as a module). The descriptor window mapping would end up being free'd twice, once in crypto4xx_build_pdr() and the second time in crypto4xx_destroy_sdr(). Fixes: 5d59ad6eea82 ("crypto: crypto4xx - fix crypto4xx_build_pdr, crypto4xx_build_sdr leak") Cc: Signed-off-by: Christian Lamparter Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: bcm - fix normal/non key hash algorithm failure

2019-12-13T07:51:25Z

[ Upstream commit 4f0129d13e69bad0363fd75553fb22897b32c379 ] Remove setkey() callback handler for normal/non key hash algorithms and keep it for AES-CBC/CMAC which needs key. Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver") Signed-off-by: Raveendra Padasalagi Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

crypto: stm32/hash - Fix hmac issue more than 256 bytes

2019-12-05T08:21:34Z

commit 0acabecebc912b3ba06289e4ef40476acc499a37 upstream. Correct condition for the second hmac loop. Key must be only set in the first loop. Initial condition was wrong, HMAC_KEY flag was not properly checked. Signed-off-by: Lionel Debieve Signed-off-by: Herbert Xu Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman