linux-kernel - [PATCH 4.16 106/161] crypto: inside-secure - fix the invalidation step during cra

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20180524093031.098530213@linuxfoundation.org>
Date:   Thu, 24 May 2018 11:38:51 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     linux-kernel@...r.kernel.org
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        stable@...r.kernel.org,
        Antoine Tenart <antoine.tenart@...tlin.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Sasha Levin <alexander.levin@...rosoft.com>
Subject: [PATCH 4.16 106/161] crypto: inside-secure - fix the invalidation step during cra_exit

4.16-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Antoine Tenart <antoine.tenart@...tlin.com>

[ Upstream commit b7007dbccd92f7b8c00e590020bee542a48c6a2c ]

When exiting a transformation, the cra_exit() helper is called in each
driver providing one. The Inside Secure SafeXcel driver has one, which
is responsible of freeing some areas and of sending one invalidation
request to the crypto engine, to invalidate the context that was used
during the transformation.

We could see in some setups (when lots of transformations were being
used with a short lifetime, and hence lots of cra_exit() calls) NULL
pointer dereferences and other weird issues. All these issues were
coming from accessing the tfm context.

The issue is the invalidation request completion is checked using a
wait_for_completion_interruptible() call in both the cipher and hash
cra_exit() helpers. In some cases this was interrupted while the
invalidation request wasn't processed yet. And then cra_exit() returned,
and its caller was freeing the tfm instance. Only then the request was
being handled by the SafeXcel driver, which lead to the said issues.

This patch fixes this by using wait_for_completion() calls in these
specific cases.

Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto engine driver")
Signed-off-by: Antoine Tenart <antoine.tenart@...tlin.com>
Signed-off-by: Herbert Xu <herbert@...dor.apana.org.au>
Signed-off-by: Sasha Levin <alexander.levin@...rosoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
---
 drivers/crypto/inside-secure/safexcel_cipher.c |    2 +-
 drivers/crypto/inside-secure/safexcel_hash.c   |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/crypto/inside-secure/safexcel_cipher.c
+++ b/drivers/crypto/inside-secure/safexcel_cipher.c
@@ -456,7 +456,7 @@ static int safexcel_cipher_exit_inv(stru
 	queue_work(priv->ring[ring].workqueue,
 		   &priv->ring[ring].work_data.work);

-	wait_for_completion_interruptible(&result.completion);
+	wait_for_completion(&result.completion);

 	if (result.error) {
 		dev_warn(priv->dev,
--- a/drivers/crypto/inside-secure/safexcel_hash.c
+++ b/drivers/crypto/inside-secure/safexcel_hash.c
@@ -496,7 +496,7 @@ static int safexcel_ahash_exit_inv(struc
 	queue_work(priv->ring[ring].workqueue,
 		   &priv->ring[ring].work_data.work);

-	wait_for_completion_interruptible(&result.completion);
+	wait_for_completion(&result.completion);

 	if (result.error) {
 		dev_warn(priv->dev, "hash: completion error (%d)\n",