linux-stable.git/drivers/crypto, branch v4.14.95

crypto: talitos - fix ablkcipher for CONFIG_VMAP_STACK

2019-01-23T07:09:48+00:00

commit 1bea445b0a022ee126ca328b3705cd4df18ebc14 upstream.

[    2.364486] WARNING: CPU: 0 PID: 60 at ./arch/powerpc/include/asm/io.h:837 dma_nommu_map_page+0x44/0xd4
[    2.373579] CPU: 0 PID: 60 Comm: cryptomgr_test Tainted: G        W         4.20.0-rc5-00560-g6bfb52e23a00-dirty #531
[    2.384740] NIP:  c000c540 LR: c000c584 CTR: 00000000
[    2.389743] REGS: c95abab0 TRAP: 0700   Tainted: G        W          (4.20.0-rc5-00560-g6bfb52e23a00-dirty)
[    2.400042] MSR:  00029032   CR: 24042204  XER: 00000000
[    2.406669]
[    2.406669] GPR00: c02f2244 c95abb60 c6262990 c95abd80 0000256a 00000001 00000001 00000001
[    2.406669] GPR08: 00000000 00002000 00000010 00000010 24042202 00000000 00000100 c95abd88
[    2.406669] GPR16: 00000000 c05569d4 00000001 00000010 c95abc88 c0615664 00000004 00000000
[    2.406669] GPR24: 00000010 c95abc88 c95abc88 00000000 c61ae210 c7ff6d40 c61ae210 00003d68
[    2.441559] NIP [c000c540] dma_nommu_map_page+0x44/0xd4
[    2.446720] LR [c000c584] dma_nommu_map_page+0x88/0xd4
[    2.451762] Call Trace:
[    2.454195] [c95abb60] [82000808] 0x82000808 (unreliable)
[    2.459572] [c95abb80] [c02f2244] talitos_edesc_alloc+0xbc/0x3c8
[    2.465493] [c95abbb0] [c02f2600] ablkcipher_edesc_alloc+0x4c/0x5c
[    2.471606] [c95abbd0] [c02f4ed0] ablkcipher_encrypt+0x20/0x64
[    2.477389] [c95abbe0] [c02023b0] __test_skcipher+0x4bc/0xa08
[    2.483049] [c95abe00] [c0204b60] test_skcipher+0x2c/0xcc
[    2.488385] [c95abe20] [c0204c48] alg_test_skcipher+0x48/0xbc
[    2.494064] [c95abe40] [c0205cec] alg_test+0x164/0x2e8
[    2.499142] [c95abf00] [c0200dec] cryptomgr_test+0x48/0x50
[    2.504558] [c95abf10] [c0039ff4] kthread+0xe4/0x110
[    2.509471] [c95abf40] [c000e1d0] ret_from_kernel_thread+0x14/0x1c
[    2.515532] Instruction dump:
[    2.518468] 7c7e1b78 7c9d2378 7cbf2b78 41820054 3d20c076 8089c200 3d20c076 7c84e850
[    2.526127] 8129c204 7c842e70 7f844840 419c0008 <0fe00000> 2f9e0000 54847022 7c84fa14
[    2.533960] ---[ end trace bf78d94af73fe3b8 ]---
[    2.539123] talitos ff020000.crypto: master data transfer error
[    2.544775] talitos ff020000.crypto: TEA error: ISR 0x20000000_00000040
[    2.551625] alg: skcipher: encryption failed on test 1 for ecb-aes-talitos: ret=22

IV cannot be on stack when CONFIG_VMAP_STACK is selected because the stack
cannot be DMA mapped anymore.

This patch copies the IV into the extended descriptor.

Fixes: 4de9d0b547b9 ("crypto: talitos - Add ablkcipher algorithms")
Cc: stable@vger.kernel.org
Signed-off-by: Christophe Leroy 
Reviewed-by: Horia Geantă 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: talitos - reorder code in talitos_edesc_alloc()

2019-01-23T07:09:48+00:00

commit c56c2e173773097a248fd3bace91ac8f6fc5386d upstream.

This patch moves the mapping of IV after the kmalloc(). This
avoids having to unmap in case kmalloc() fails.

Signed-off-by: Christophe Leroy 
Reviewed-by: Horia Geantă 
Cc: stable@vger.kernel.org
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: bcm - convert to use crypto_authenc_extractkeys()

2019-01-23T07:09:47+00:00

commit ab57b33525c3221afaebd391458fa0cbcd56903d upstream.

Convert the bcm crypto driver to use crypto_authenc_extractkeys() so
that it picks up the fix for broken validation of rtattr::rta_len.

This also fixes the DES weak key check to actually be done on the right
key. (It was checking the authentication key, not the encryption key...)

Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver")
Cc:  # v4.11+
Signed-off-by: Eric Biggers 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: caam - fix zero-length buffer DMA mapping

2019-01-23T07:09:47+00:00

commit 04e6d25c5bb244c1a37eb9fe0b604cc11a04e8c5 upstream.

Recent changes - probably DMA API related (generic and/or arm64-specific) -
exposed a case where driver maps a zero-length buffer:
ahash_init()->ahash_update()->ahash_final() with a zero-length string to
hash

kernel BUG at kernel/dma/swiotlb.c:475!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
Modules linked in:
CPU: 2 PID: 1823 Comm: cryptomgr_test Not tainted 4.20.0-rc1-00108-g00c9fe37a7f2 #1
Hardware name: LS1046A RDB Board (DT)
pstate: 80000005 (Nzcv daif -PAN -UAO)
pc : swiotlb_tbl_map_single+0x170/0x2b8
lr : swiotlb_map_page+0x134/0x1f8
sp : ffff00000f79b8f0
x29: ffff00000f79b8f0 x28: 0000000000000000
x27: ffff0000093d0000 x26: 0000000000000000
x25: 00000000001f3ffe x24: 0000000000200000
x23: 0000000000000000 x22: 00000009f2c538c0
x21: ffff800970aeb410 x20: 0000000000000001
x19: ffff800970aeb410 x18: 0000000000000007
x17: 000000000000000e x16: 0000000000000001
x15: 0000000000000019 x14: c32cb8218a167fe8
x13: ffffffff00000000 x12: ffff80097fdae348
x11: 0000800976bca000 x10: 0000000000000010
x9 : 0000000000000000 x8 : ffff0000091fd6c8
x7 : 0000000000000000 x6 : 00000009f2c538bf
x5 : 0000000000000000 x4 : 0000000000000001
x3 : 0000000000000000 x2 : 00000009f2c538c0
x1 : 00000000f9fff000 x0 : 0000000000000000
Process cryptomgr_test (pid: 1823, stack limit = 0x(____ptrval____))
Call trace:
 swiotlb_tbl_map_single+0x170/0x2b8
 swiotlb_map_page+0x134/0x1f8
 ahash_final_no_ctx+0xc4/0x6cc
 ahash_final+0x10/0x18
 crypto_ahash_op+0x30/0x84
 crypto_ahash_final+0x14/0x1c
 __test_hash+0x574/0xe0c
 test_hash+0x28/0x80
 __alg_test_hash+0x84/0xd0
 alg_test_hash+0x78/0x144
 alg_test.part.30+0x12c/0x2b4
 alg_test+0x3c/0x68
 cryptomgr_test+0x44/0x4c
 kthread+0xfc/0x128
 ret_from_fork+0x10/0x18
Code: d34bfc18 2a1a03f7 1a9f8694 35fff89a (d4210000)

Cc: 
Signed-off-by: Aymen Sghaier 
Signed-off-by: Horia Geantă 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: cavium/nitrox - fix a DMA pool free failure

2019-01-09T16:14:50+00:00

commit 7172122be6a4712d699da4d261f92aa5ab3a78b8 upstream.

In crypto_alloc_context(), a DMA pool is allocated through dma_pool_alloc()
to hold the crypto context. The meta data of the DMA pool, including the
pool used for the allocation 'ndev->ctx_pool' and the base address of the
DMA pool used by the device 'dma', are then stored to the beginning of the
pool. These meta data are eventually used in crypto_free_context() to free
the DMA pool through dma_pool_free(). However, given that the DMA pool can
also be accessed by the device, a malicious device can modify these meta
data, especially when the device is controlled to deploy an attack. This
can cause an unexpected DMA pool free failure.

To avoid the above issue, this patch introduces a new structure
crypto_ctx_hdr and a new field chdr in the structure nitrox_crypto_ctx hold
the meta data information of the DMA pool after the allocation. Note that
the original structure ctx_hdr is not changed to ensure the compatibility.

Cc: 
Signed-off-by: Wenwen Wang 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: caam - fix implicit casts in endianness helpers

2018-11-13T19:14:59+00:00

[ Upstream commit aae733a3f46f5ef338fbdde26e14cbb205a23de0 ]

Fix the following sparse endianness warnings:

drivers/crypto/caam/regs.h:95:1: sparse: incorrect type in return expression (different base types) @@    expected unsigned int @@    got restricted __le32unsigned int @@
drivers/crypto/caam/regs.h:95:1:    expected unsigned int
drivers/crypto/caam/regs.h:95:1:    got restricted __le32 [usertype] 
drivers/crypto/caam/regs.h:95:1: sparse: incorrect type in return expression (different base types) @@    expected unsigned int @@    got restricted __be32unsigned int @@
drivers/crypto/caam/regs.h:95:1:    expected unsigned int
drivers/crypto/caam/regs.h:95:1:    got restricted __be32 [usertype] 

drivers/crypto/caam/regs.h:92:1: sparse: cast to restricted __le32
drivers/crypto/caam/regs.h:92:1: sparse: cast to restricted __be32

Fixes: 261ea058f016 ("crypto: caam - handle core endianness != caam endianness")
Reported-by: kbuild test robot 
Signed-off-by: Horia Geantă 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

crypto: chelsio - Fix memory corruption in DMA Mapped buffers.

2018-10-13T07:27:28+00:00

commit add92a817e60e308a419693413a38d9d1e663aff upstream.

Update PCI Id in "cpl_rx_phys_dsgl" header. In case pci_chan_id and
tx_chan_id are not derived from same queue, H/W can send request
completion indication before completing DMA Transfer.

Herbert, It would be good if fix can be merge to stable tree.
For 4.14 kernel, It requires some update to avoid mege conficts.

Cc: 
Signed-off-by: Harsh Jain 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: caam/jr - fix ablkcipher_edesc pointer arithmetic

2018-10-10T06:54:28+00:00

commit 13cc6f48c7434ce46ba6dbc90003a136a263d75a upstream.

In some cases the zero-length hw_desc array at the end of
ablkcipher_edesc struct requires for 4B of tail padding.

Due to tail padding and the way pointers to S/G table and IV
are computed:
	edesc->sec4_sg = (void *)edesc + sizeof(struct ablkcipher_edesc) +
			 desc_bytes;
	iv = (u8 *)edesc->hw_desc + desc_bytes + sec4_sg_bytes;
first 4 bytes of IV are overwritten by S/G table.

Update computation of pointer to S/G table to rely on offset of hw_desc
member and not on sizeof() operator.

Cc:  # 4.13+
Fixes: 115957bb3e59 ("crypto: caam - fix IV DMA mapping and updating")
Signed-off-by: Horia Geantă 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: mxs-dcp - Fix wait logic on chan threads

2018-10-10T06:54:27+00:00

commit d80771c08363ad7fbf0f56f5301e7ca65065c582 upstream.

When compiling with CONFIG_DEBUG_ATOMIC_SLEEP=y the mxs-dcp driver
prints warnings such as:

WARNING: CPU: 0 PID: 120 at kernel/sched/core.c:7736 __might_sleep+0x98/0x9c
do not call blocking ops when !TASK_RUNNING; state=1 set at [<8081978c>] dcp_chan_thread_sha+0x3c/0x2ec

The problem is that blocking ops will manipulate current->state
themselves so it is not allowed to call them between
set_current_state(TASK_INTERRUPTIBLE) and schedule().

Fix this by converting the per-chan mutex to a spinlock (it only
protects tiny list ops anyway) and rearranging the wait logic so that
callbacks are called current->state as TASK_RUNNING. Those callbacks
will indeed call blocking ops themselves so this is required.

Cc: 
Signed-off-by: Leonard Crestez 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: qat - Fix KASAN stack-out-of-bounds bug in adf_probe()

2018-10-10T06:54:27+00:00

commit ba439a6cbfa2936a6713f64cb499de7943673fe3 upstream.

The following KASAN warning was printed when booting a 64-bit kernel
on some systems with Intel CPUs:

[   44.512826] ==================================================================
[   44.520165] BUG: KASAN: stack-out-of-bounds in find_first_bit+0xb0/0xc0
[   44.526786] Read of size 8 at addr ffff88041e02fc50 by task kworker/0:2/124

[   44.535253] CPU: 0 PID: 124 Comm: kworker/0:2 Tainted: G               X --------- ---  4.18.0-12.el8.x86_64+debug #1
[   44.545858] Hardware name: Intel Corporation PURLEY/PURLEY, BIOS BKVDTRL1.86B.0005.D08.1712070559 12/07/2017
[   44.555682] Workqueue: events work_for_cpu_fn
[   44.560043] Call Trace:
[   44.562502]  dump_stack+0x9a/0xe9
[   44.565832]  print_address_description+0x65/0x22e
[   44.570683]  ? find_first_bit+0xb0/0xc0
[   44.570689]  kasan_report.cold.6+0x92/0x19f
[   44.578726]  find_first_bit+0xb0/0xc0
[   44.578737]  adf_probe+0x9eb/0x19a0 [qat_c62x]
[   44.578751]  ? adf_remove+0x110/0x110 [qat_c62x]
[   44.591490]  ? mark_held_locks+0xc8/0x140
[   44.591498]  ? _raw_spin_unlock+0x30/0x30
[   44.591505]  ? trace_hardirqs_on_caller+0x381/0x570
[   44.604418]  ? adf_remove+0x110/0x110 [qat_c62x]
[   44.604427]  local_pci_probe+0xd4/0x180
[   44.604432]  ? pci_device_shutdown+0x110/0x110
[   44.617386]  work_for_cpu_fn+0x51/0xa0
[   44.621145]  process_one_work+0x8fe/0x16e0
[   44.625263]  ? pwq_dec_nr_in_flight+0x2d0/0x2d0
[   44.629799]  ? lock_acquire+0x14c/0x400
[   44.633645]  ? move_linked_works+0x12e/0x2a0
[   44.637928]  worker_thread+0x536/0xb50
[   44.641690]  ? __kthread_parkme+0xb6/0x180
[   44.645796]  ? process_one_work+0x16e0/0x16e0
[   44.650160]  kthread+0x30c/0x3d0
[   44.653400]  ? kthread_create_worker_on_cpu+0xc0/0xc0
[   44.658457]  ret_from_fork+0x3a/0x50

[   44.663557] The buggy address belongs to the page:
[   44.668350] page:ffffea0010780bc0 count:0 mapcount:0 mapping:0000000000000000 index:0x0
[   44.676356] flags: 0x17ffffc0000000()
[   44.680023] raw: 0017ffffc0000000 ffffea0010780bc8 ffffea0010780bc8 0000000000000000
[   44.687769] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
[   44.695510] page dumped because: kasan: bad access detected

[   44.702578] Memory state around the buggy address:
[   44.707372]  ffff88041e02fb00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   44.714593]  ffff88041e02fb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   44.721810] >ffff88041e02fc00: 00 00 00 00 00 00 f1 f1 f1 f1 04 f2 f2 f2 f2 f2
[   44.729028]                                                  ^
[   44.734864]  ffff88041e02fc80: f2 f2 00 00 00 00 f3 f3 f3 f3 00 00 00 00 00 00
[   44.742082]  ffff88041e02fd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   44.749299] ==================================================================

Looking into the code:

  int ret, bar_mask;
    :
  for_each_set_bit(bar_nr, (const unsigned long *)&bar_mask,

It is casting a 32-bit integer pointer to a 64-bit unsigned long
pointer. There are two problems here. First, the 32-bit pointer address
may not be 64-bit aligned. Secondly, it is accessing an extra 4 bytes.

This is fixed by changing the bar_mask type to unsigned long.

Cc: 
Signed-off-by: Waiman Long 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman