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

crypto: omap-aes - Fix PM disable depth imbalance in omap_aes_probe

2020-12-29T12:44:55+00:00

[ Upstream commit ff8107200367f4abe0e5bce66a245e8d0f2d229e ]

The pm_runtime_enable will increase power disable depth.
Thus a pairing decrement is needed on the error handling
path to keep it balanced according to context.

Fixes: f7b2b5dd6a62a ("crypto: omap-aes - add error check for pm_runtime_get_sync")
Signed-off-by: Zhang Qilong 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

crypto: talitos - Fix return type of current_desc_hdr()

2020-12-29T12:44:53+00:00

[ Upstream commit 0237616173fd363a54bd272aa3bd376faa1d7caa ]

current_desc_hdr() returns a u32 but in fact this is a __be32,
leading to a lot of sparse warnings.

Change the return type to __be32 and ensure it is handled as
sure by the caller.

Fixes: 3e721aeb3df3 ("crypto: talitos - handle descriptor not found in error path")
Signed-off-by: Christophe Leroy 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

crypto: ccp - fix error handling

2020-10-29T08:05:41+00:00

[ Upstream commit e356c49c6cf0db3f00e1558749170bd56e47652d ]

Fix resource leak in error handling.

Signed-off-by: Pavel Machek (CIP) 
Acked-by: John Allen 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

crypto: omap-sham - fix digcnt register handling with export/import

2020-10-29T08:05:33+00:00

[ Upstream commit 3faf757bad75f3fc1b2736f0431e295a073a7423 ]

Running export/import for hashes in peculiar order (mostly done by
openssl) can mess up the internal book keeping of the OMAP SHA core.
Fix by forcibly writing the correct DIGCNT back to hardware. This issue
was noticed while transitioning to openssl 1.1 support.

Fixes: 0d373d603202 ("crypto: omap-sham - Add OMAP4/AM33XX SHAM Support")
Signed-off-by: Tero Kristo 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

crypto: ixp4xx - Fix the size used in a 'dma_free_coherent()' call

2020-10-29T08:05:32+00:00

[ Upstream commit f7ade9aaf66bd5599690acf0597df2c0f6cd825a ]

Update the size used in 'dma_free_coherent()' in order to match the one
used in the corresponding 'dma_alloc_coherent()', in 'setup_crypt_desc()'.

Fixes: 81bef0150074 ("crypto: ixp4xx - Hardware crypto support for IXP4xx CPUs")
Signed-off-by: Christophe JAILLET 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

crypto: qat - check cipher length for aead AES-CBC-HMAC-SHA

2020-10-17T09:02:21+00:00

commit 45cb6653b0c355fc1445a8069ba78a4ce8720511 upstream.

Return -EINVAL for authenc(hmac(sha1),cbc(aes)),
authenc(hmac(sha256),cbc(aes)) and authenc(hmac(sha512),cbc(aes))
if the cipher length is not multiple of the AES block.
This is to prevent an undefined device behaviour.

Fixes: d370cec32194 ("crypto: qat - Intel(R) QAT crypto interface")
Cc: 
Signed-off-by: Dominik Przychodni 
[giovanni.cabiddu@intel.com: reworded commit message]
Signed-off-by: Giovanni Cabiddu 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: ccp - Fix use of merged scatterlists

2020-08-21T09:02:05+00:00

commit 8a302808c60d441d9884cb00ea7f2b534f2e3ca5 upstream.

Running the crypto manager self tests with
CONFIG_CRYPTO_MANAGER_EXTRA_TESTS may result in several types of errors
when using the ccp-crypto driver:

alg: skcipher: cbc-des3-ccp encryption failed on test vector 0; expected_error=0, actual_error=-5 ...

alg: skcipher: ctr-aes-ccp decryption overran dst buffer on test vector 0 ...

alg: ahash: sha224-ccp test failed (wrong result) on test vector ...

These errors are the result of improper processing of scatterlists mapped
for DMA.

Given a scatterlist in which entries are merged as part of mapping the
scatterlist for DMA, the DMA length of a merged entry will reflect the
combined length of the entries that were merged. The subsequent
scatterlist entry will contain DMA information for the scatterlist entry
after the last merged entry, but the non-DMA information will be that of
the first merged entry.

The ccp driver does not take this scatterlist merging into account. To
address this, add a second scatterlist pointer to track the current
position in the DMA mapped representation of the scatterlist. Both the DMA
representation and the original representation of the scatterlist must be
tracked as while most of the driver can use just the DMA representation,
scatterlist_map_and_copy() must use the original representation and
expects the scatterlist pointer to be accurate to the original
representation.

In order to properly walk the original scatterlist, the scatterlist must
be walked until the combined lengths of the entries seen is equal to the
DMA length of the current entry being processed in the DMA mapped
representation.

Fixes: 63b945091a070 ("crypto: ccp - CCP device driver and interface support")
Signed-off-by: John Allen 
Cc: stable@vger.kernel.org
Acked-by: Tom Lendacky 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: qat - fix double free in qat_uclo_create_batch_init_list

2020-08-21T09:02:05+00:00

commit c06c76602e03bde24ee69a2022a829127e504202 upstream.

clang static analysis flags this error

qat_uclo.c:297:3: warning: Attempt to free released memory
  [unix.Malloc]
                kfree(*init_tab_base);
                ^~~~~~~~~~~~~~~~~~~~~

When input *init_tab_base is null, the function allocates memory for
the head of the list.  When there is problem allocating other list
elements the list is unwound and freed.  Then a check is made if the
list head was allocated and is also freed.

Keeping track of the what may need to be freed is the variable 'tail_old'.
The unwinding/freeing block is

	while (tail_old) {
		mem_init = tail_old->next;
		kfree(tail_old);
		tail_old = mem_init;
	}

The problem is that the first element of tail_old is also what was
allocated for the list head

		init_header = kzalloc(sizeof(*init_header), GFP_KERNEL);
		...
		*init_tab_base = init_header;
		flag = 1;
	}
	tail_old = init_header;

So *init_tab_base/init_header are freed twice.

There is another problem.
When the input *init_tab_base is non null the tail_old is calculated by
traveling down the list to first non null entry.

	tail_old = init_header;
	while (tail_old->next)
		tail_old = tail_old->next;

When the unwinding free happens, the last entry of the input list will
be freed.

So the freeing needs a general changed.
If locally allocated the first element of tail_old is freed, else it
is skipped.  As a bit of cleanup, reset *init_tab_base if it came in
as null.

Fixes: b4b7e67c917f ("crypto: qat - Intel(R) QAT ucode part of fw loader")
Cc: 
Signed-off-by: Tom Rix 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: ccp - Release all allocated memory if sha type is invalid

2020-08-21T09:01:47+00:00

[ Upstream commit 128c66429247add5128c03dc1e144ca56f05a4e2 ]

Release all allocated memory if sha type is invalid:
In ccp_run_sha_cmd, if the type of sha is invalid, the allocated
hmac_buf should be released.

v2: fix the goto.

Signed-off-by: Navid Emamdoost 
Acked-by: Gary R Hook 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

crypto: omap-sham - add proper load balancing support for multicore

2020-06-30T19:38:29+00:00

[ Upstream commit 281c377872ff5d15d80df25fc4df02d2676c7cde ]

The current implementation of the multiple accelerator core support for
OMAP SHA does not work properly. It always picks up the first probed
accelerator core if this is available, and rest of the book keeping also
gets confused if there are two cores available. Add proper load
balancing support for SHA, and also fix any bugs related to the
multicore support while doing it.

Signed-off-by: Tero Kristo 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin