linux.git/drivers/crypto, branch v5.0.4

crypto: rockchip - update new iv to device in multiple operations

2019-03-23T19:11:13+00:00

commit c1c214adcb56d36433480c8fedf772498e7e539c upstream.

For chain mode in cipher(eg. AES-CBC/DES-CBC), the iv is continuously
updated in the operation. The new iv value should be written to device
register by software.

Reported-by: Eric Biggers 
Fixes: 433cd2c617bf ("crypto: rockchip - add crypto driver for rk3288")
Cc:  # v4.5+
Signed-off-by: Zhang Zhijie 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: rockchip - fix scatterlist nents error

2019-03-23T19:11:13+00:00

commit 4359669a087633132203c52d67dd8c31e09e7b2e upstream.

In some cases, the nents of src scatterlist is different from
dst scatterlist. So two variables are used to handle the nents
of src&dst scatterlist.

Reported-by: Eric Biggers 
Fixes: 433cd2c617bf ("crypto: rockchip - add crypto driver for rk3288")
Cc:  # v4.5+
Signed-off-by: Zhang Zhijie 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: ccree - don't copy zero size ciphertext

2019-03-23T19:11:13+00:00

commit 2b5ac17463dcb2411fed506edcf259a89bb538ba upstream.

For decryption in CBC mode we need to save the last ciphertext block
for use as the next IV. However, we were trying to do this also with
zero sized ciphertext resulting in a panic.

Fix this by only doing the copy if the ciphertext length is at least
of IV size.

Signed-off-by: Gilad Ben-Yossef 
Cc: stable@vger.kernel.org
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: ccree - unmap buffer before copying IV

2019-03-23T19:11:12+00:00

commit c139c72e2beb3e3db5148910b3962b7322e24374 upstream.

We were copying the last ciphertext block into the IV field
for CBC before removing the DMA mapping of the output buffer
with the result of the buffer sometime being out-of-sync cache
wise and were getting intermittent cases of bad output IV.

Fix it by moving the DMA buffer unmapping before the copy.

Signed-off-by: Gilad Ben-Yossef 
Fixes: 00904aa0cd59 ("crypto: ccree - fix iv handling")
Cc: 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: ccree - fix free of unallocated mlli buffer

2019-03-23T19:11:12+00:00

commit a49411959ea6d4915a9fd2a7eb5ba220e6284e9a upstream.

In cc_unmap_aead_request(), call dma_pool_free() for mlli buffer only
if an item is allocated from the pool and not always if there is a
pool allocated.
This fixes a kernel panic when trying to free a non-allocated item.

Cc: stable@vger.kernel.org
Signed-off-by: Hadar Gat 
Signed-off-by: Gilad Ben-Yossef 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: caam - fix DMA mapping of stack memory

2019-03-23T19:11:12+00:00

commit c19650d6ea99bcd903d3e55dd61860026c701339 upstream.

Roland reports the following issue and provides a root cause analysis:

"On a v4.19 i.MX6 system with IMA and CONFIG_DMA_API_DEBUG enabled, a
warning is generated when accessing files on a filesystem for which IMA
measurement is enabled:

    ------------[ cut here ]------------
    WARNING: CPU: 0 PID: 1 at kernel/dma/debug.c:1181 check_for_stack.part.9+0xd0/0x120
    caam_jr 2101000.jr0: DMA-API: device driver maps memory from stack [addr=b668049e]
    Modules linked in:
    CPU: 0 PID: 1 Comm: switch_root Not tainted 4.19.0-20181214-1 #2
    Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
    Backtrace:
    [] (dump_backtrace) from [] (show_stack+0x20/0x24)
    [] (show_stack) from [] (dump_stack+0xa0/0xcc)
    [] (dump_stack) from [] (__warn+0xf0/0x108)
    [] (__warn) from [] (warn_slowpath_fmt+0x58/0x74)
    [] (warn_slowpath_fmt) from [] (check_for_stack.part.9+0xd0/0x120)
    [] (check_for_stack.part.9) from [] (debug_dma_map_page+0x144/0x174)
    [] (debug_dma_map_page) from [] (ahash_final_ctx+0x5b4/0xcf0)
    [] (ahash_final_ctx) from [] (ahash_final+0x1c/0x20)
    [] (ahash_final) from [] (crypto_ahash_op+0x38/0x80)
    [] (crypto_ahash_op) from [] (crypto_ahash_final+0x20/0x24)
    [] (crypto_ahash_final) from [] (ima_calc_file_hash+0x29c/0xa40)
    [] (ima_calc_file_hash) from [] (ima_collect_measurement+0x1dc/0x240)
    [] (ima_collect_measurement) from [] (process_measurement+0x4c4/0x6b8)
    [] (process_measurement) from [] (ima_file_check+0x88/0xa4)
    [] (ima_file_check) from [] (path_openat+0x5d8/0x1364)
    [] (path_openat) from [] (do_filp_open+0x84/0xf0)
    [] (do_filp_open) from [] (do_open_execat+0x84/0x1b0)
    [] (do_open_execat) from [] (__do_execve_file+0x43c/0x890)
    [] (__do_execve_file) from [] (sys_execve+0x44/0x4c)
    [] (sys_execve) from [] (ret_fast_syscall+0x0/0x28)
    ---[ end trace 3455789a10e3aefd ]---

The cause is that the struct ahash_request *req is created as a
stack-local variable up in the stack (presumably somewhere in the IMA
implementation), then passed down into the CAAM driver, which tries to
dma_single_map the req->result (indirectly via map_seq_out_ptr_result)
in order to make that buffer available for the CAAM to store the result
of the following hash operation.

The calling code doesn't know how req will be used by the CAAM driver,
and there could be other such occurrences where stack memory is passed
down to the CAAM driver. Therefore we should rather fix this issue in
the CAAM driver where the requirements are known."

Fix this problem by:
-instructing the crypto engine to write the final hash in state->caam_ctx
-subsequently memcpy-ing the final hash into req->result

Cc:  # v4.19+
Reported-by: Roland Hieber 
Signed-off-by: Horia Geantă 
Tested-by: Roland Hieber 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: caam - fixed handling of sg list

2019-03-23T19:11:12+00:00

commit 42e95d1f10dcf8b18b1d7f52f7068985b3dc5b79 upstream.

when the source sg contains more than 1 fragment and
destination sg contains 1 fragment, the caam driver
mishandle the buffers to be sent to caam.

Fixes: f2147b88b2b1 ("crypto: caam - Convert GCM to new AEAD interface")
Cc:  # 4.2+
Signed-off-by: Pankaj Gupta 
Signed-off-by: Arun Pathak 
Reviewed-by: Horia Geanta 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: ccree - fix missing break in switch statement

2019-03-23T19:11:12+00:00

commit b5be853181a8d4a6e20f2073ccd273d6280cad88 upstream.

Add missing break statement in order to prevent the code from falling
through to case S_DIN_to_DES.

This bug was found thanks to the ongoing efforts to enable
-Wimplicit-fallthrough.

Fixes: 63ee04c8b491 ("crypto: ccree - add skcipher support")
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: caam - fix hash context DMA unmap size

2019-03-23T19:11:12+00:00

commit 65055e2108847af5e577cc7ce6bde45ea136d29a upstream.

When driver started using state->caam_ctxt for storing both running hash
and final hash, it was not updated to handle different DMA unmap
lengths.

Cc:  # v4.19+
Fixes: c19650d6ea99 ("crypto: caam - fix DMA mapping of stack memory")
Signed-off-by: Franck LENORMAND 
Signed-off-by: Horia Geantă 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6

2019-02-28T17:05:18+00:00

Pull crypto fixes from Herbert Xu:
 "This fixes a compiler warning introduced by a previous fix, as well as
  two crash bugs on ARM"

* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
  crypto: sha512/arm - fix crash bug in Thumb2 build
  crypto: sha256/arm - fix crash bug in Thumb2 build
  crypto: ccree - add missing inline qualifier