linux-stable.git/drivers/crypto/marvell, branch linux-5.7.y

crypto: marvell/octeontx - Fix a potential NULL dereference

2020-06-24T15:49:13+00:00

[ Upstream commit 1f5b07f5dd1748a6f9363fb1a76d599c74af8231 ]

Smatch reports that:

    drivers/crypto/marvell/octeontx/otx_cptvf_algs.c:132 otx_cpt_aead_callback()
    warn: variable dereferenced before check 'cpt_info' (see line 121)

This function is called from process_pending_queue() as:

drivers/crypto/marvell/octeontx/otx_cptvf_reqmgr.c
   599                  /*
   600                   * Call callback after current pending entry has been
   601                   * processed, we don't do it if the callback pointer is
   602                   * invalid.
   603                   */
   604                  if (callback)
   605                          callback(res_code, areq, cpt_info);

It does appear to me that "cpt_info" can be NULL so this could lead to
a NULL dereference.

Fixes: 10b4f09491bf ("crypto: marvell - add the Virtual Function driver for CPT")
Signed-off-by: Dan Carpenter 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

crypto: marvell/octeontx - fix double free of ptr

2020-04-03T04:37:26+00:00

Currently in the case where eq->src != req->ds, the allocation of
ptr is kfree'd at the end of the code block. However later on in
the case where enc is not null any of the error return paths that
return via the error handling return path end up performing an
erroneous second kfree of ptr.

Fix this by adding an error exit label error_free and only jump to
this when ptr needs kfree'ing thus avoiding the double free issue.

Addresses-Coverity: ("Double free")
Fixes: 10b4f09491bf ("crypto: marvell - add the Virtual Function driver for CPT")
Signed-off-by: Colin Ian King 
Signed-off-by: Herbert Xu

crypto: marvell - enable OcteonTX cpt options for build

2020-03-20T03:36:52+00:00

Add the OcteonTX cpt options in crypto Kconfig and Makefile

Signed-off-by: SrujanaChalla 
Signed-off-by: Herbert Xu

crypto: marvell - add the Virtual Function driver for CPT

2020-03-20T03:36:52+00:00

Add support for the cryptographic accelerator unit virtual functions on
OcteonTX 83XX SoC.

Co-developed-by: Lukasz Bartosik 
Signed-off-by: Lukasz Bartosik 
Signed-off-by: SrujanaChalla 
Signed-off-by: Herbert Xu

crypto: marvell - add support for OCTEON TX CPT engine

2020-03-20T03:36:51+00:00

Add support for the cryptographic acceleration unit (CPT) on
OcteonTX CN83XX SoC.

Co-developed-by: Lukasz Bartosik 
Signed-off-by: Lukasz Bartosik 
Signed-off-by: SrujanaChalla 
Signed-off-by: Herbert Xu

crypto: marvell - create common Kconfig and Makefile for Marvell

2020-03-20T03:36:51+00:00

Creats common Kconfig and Makefile for Marvell crypto drivers.

Signed-off-by: SrujanaChalla 
Signed-off-by: Herbert Xu

crypto: remove CRYPTO_TFM_RES_BAD_KEY_LEN

2020-01-09T03:30:53+00:00

The CRYPTO_TFM_RES_BAD_KEY_LEN flag was apparently meant as a way to
make the ->setkey() functions provide more information about errors.

However, no one actually checks for this flag, which makes it pointless.

Also, many algorithms fail to set this flag when given a bad length key.
Reviewing just the generic implementations, this is the case for
aes-fixed-time, cbcmac, echainiv, nhpoly1305, pcrypt, rfc3686, rfc4309,
rfc7539, rfc7539esp, salsa20, seqiv, and xcbc.  But there are probably
many more in arch/*/crypto/ and drivers/crypto/.

Some algorithms can even set this flag when the key is the correct
length.  For example, authenc and authencesn set it when the key payload
is malformed in any way (not just a bad length), the atmel-sha and ccree
drivers can set it if a memory allocation fails, and the chelsio driver
sets it for bad auth tag lengths, not just bad key lengths.

So even if someone actually wanted to start checking this flag (which
seems unlikely, since it's been unused for a long time), there would be
a lot of work needed to get it working correctly.  But it would probably
be much better to go back to the drawing board and just define different
return values, like -EINVAL if the key is invalid for the algorithm vs.
-EKEYREJECTED if the key was rejected by a policy like "no weak keys".
That would be much simpler, less error-prone, and easier to test.

So just remove this flag.

Signed-off-by: Eric Biggers 
Reviewed-by: Horia Geantă 
Signed-off-by: Herbert Xu

crypto: marvell/cesa - rename blkcipher to skcipher

2019-11-17T01:02:49+00:00

The driver specific types contain some rudimentary references to the
blkcipher API, which is deprecated and will be removed. To avoid confusion,
rename these to skcipher. This is a cosmetic change only, as the code does
not actually use the blkcipher API.

Signed-off-by: Ard Biesheuvel 
Signed-off-by: Herbert Xu

crypto: marvell - Use kzfree rather than its implementation

2019-09-09T13:48:40+00:00

Use kzfree instead of memset() + kfree().

Signed-off-by: zhong jiang 
Signed-off-by: Herbert Xu

crypto: cesa/des - switch to new verification routines

2019-08-22T04:57:31+00:00

Signed-off-by: Ard Biesheuvel 
Signed-off-by: Herbert Xu