Patch "crypto: inside-secure - fix request allocations in invalidation path" has been added to the 4.14-stable tree
Subsystems (3)
This is a note to let you know that I've just added the patch titled
crypto: inside-secure - fix request allocations in invalidation path
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
crypto-inside-secure-fix-request-allocations-in-invalidation-path.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.
Quoted 1 line
From foo@baz Wed Feb 28 16:23:28 CET 2018
From: "Antoine T�nart" <[email protected]>
Date: Mon, 11 Dec 2017 12:10:57 +0100
Subject: crypto: inside-secure - fix request allocations in invalidation path
From: "Antoine T�nart" <[email protected]>
[ Upstream commit 7cad2fabd5691dbb17762877d4e7f236fe4bc181 ]
This patch makes use of the SKCIPHER_REQUEST_ON_STACK and AHASH_REQUEST_ON_STACK helpers to allocate enough memory to contain both the crypto request structures and their embedded context (__ctx).
--- drivers/crypto/inside-secure/safexcel_cipher.c | 16 ++++++++-------- drivers/crypto/inside-secure/safexcel_hash.c | 14 +++++++------- 2 files changed, 15 insertions(+), 15 deletions(-)
drivers/crypto/inside-secure/safexcel_cipher.c +8 -8
@@ -422,25 +422,25 @@ static int safexcel_cipher_exit_inv(stru {struct safexcel_cipher_ctx *ctx =crypto_tfm_ctx (tfm);struct safexcel_crypto_priv *priv = ctx->priv; -struct skcipher_request req; -struct safexcel_cipher_req *sreq =skcipher_request_ctx (&req); +SKCIPHER_REQUEST_ON_STACK (req,__crypto_skcipher_cast (tfm)); +struct safexcel_cipher_req *sreq =skcipher_request_ctx (req);struct safexcel_inv_result result = {};int ring = ctx->base.ring; -memset (&req,0 ,sizeof (struct skcipher_request )); +memset (req,0 ,sizeof (struct skcipher_request ));/* create invalidation request */ init_completion (&result.completion); -skcipher_request_set_callback (&req,CRYPTO_TFM_REQ_MAY_BACKLOG , - safexcel_inv_complete, &result); +skcipher_request_set_callback (req,CRYPTO_TFM_REQ_MAY_BACKLOG , + safexcel_inv_complete, &result); -skcipher_request_set_tfm (&req,__crypto_skcipher_cast (tfm)); - ctx =crypto_tfm_ctx (req.base.tfm); +skcipher_request_set_tfm (req,__crypto_skcipher_cast (tfm)); + ctx =crypto_tfm_ctx (req->base.tfm); ctx->base.exit_inv = true; sreq->needs_inv = true;spin_lock_bh (&priv->ring[ring].queue_lock); -crypto_enqueue_request (&priv->ring[ring].queue, &req.base); +crypto_enqueue_request (&priv->ring[ring].queue, &req->base);spin_unlock_bh (&priv->ring[ring].queue_lock);if (!priv->ring[ring].need_dequeue)
drivers/crypto/inside-secure/safexcel_hash.c +7 -7
@@ -470,25 +470,25 @@ static int safexcel_ahash_exit_inv(struc {struct safexcel_ahash_ctx *ctx =crypto_tfm_ctx (tfm);struct safexcel_crypto_priv *priv = ctx->priv; -struct ahash_request req; -struct safexcel_ahash_req *rctx =ahash_request_ctx (&req); +AHASH_REQUEST_ON_STACK (req,__crypto_ahash_cast (tfm)); +struct safexcel_ahash_req *rctx =ahash_request_ctx (req);struct safexcel_inv_result result = {};int ring = ctx->base.ring; -memset (&req,0 ,sizeof (struct ahash_request )); +memset (req,0 ,sizeof (struct ahash_request ));/* create invalidation request */ init_completion (&result.completion); -ahash_request_set_callback (&req,CRYPTO_TFM_REQ_MAY_BACKLOG , +ahash_request_set_callback (req,CRYPTO_TFM_REQ_MAY_BACKLOG , safexcel_inv_complete, &result); -ahash_request_set_tfm (&req,__crypto_ahash_cast (tfm)); - ctx =crypto_tfm_ctx (req.base.tfm); +ahash_request_set_tfm (req,__crypto_ahash_cast (tfm)); + ctx =crypto_tfm_ctx (req->base.tfm); ctx->base.exit_inv = true; rctx->needs_inv = true;spin_lock_bh (&priv->ring[ring].queue_lock); -crypto_enqueue_request (&priv->ring[ring].queue, &req.base); +crypto_enqueue_request (&priv->ring[ring].queue, &req->base);spin_unlock_bh (&priv->ring[ring].queue_lock);if (!priv->ring[ring].need_dequeue)
Patches currently in stable-queue which might be from [email protected] are
queue-4.14/crypto-inside-secure-per-request-invalidation.patch queue-4.14/crypto-inside-secure-fix-request-allocations-in-invalidation-path.patch queue-4.14/crypto-inside-secure-free-requests-even-if-their-handling-failed.patch