diff mbox

BUG: algif_hash crash with extra recv() in 4.9-rc5

Message ID 20161117140757.GA1149@gondor.apana.org.au (mailing list archive)
State Accepted
Delegated to: Herbert Xu
Headers show

Commit Message

Herbert Xu Nov. 17, 2016, 2:07 p.m. UTC
On Wed, Nov 16, 2016 at 11:17:33AM -0800, Mat Martineau wrote:
> 
> Herbert -
> 
> Following commit 493b2ed3f7603a15ff738553384d5a4510ffeb95, there is a NULL
> dereference crash in algif_hash when recv() is called twice like this:
> 
> send(sk, data, len, MSG_MORE);
> recv(sk, hash1, len, 0);
> recv(sk, hash2, len, 0);
> 
> In 4.8 and earlier, the two recvs return identical data. In 4.9-rc5, the
> second recv triggers this:
> 
> [   53.041287] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
> [   53.042048] IP: [<ffffffffa73fdfb3>] shash_ahash_digest+0x23/0x130

Ugh.  It looks like the shash wrapper is incorrectly dereferencing
the SG list even when the length is zero.  Rather than fixing it
I'm just going to make algif_hash do the safe thing of doing an
init followed by a final.

Thanks,

---8<---
Subject: crypto: algif_hash - Fix NULL hash crash with shash

Recently algif_hash has been changed to allow null hashes.  This
triggers a bug when used with an shash algorithm whereby it will
cause a crash during the digest operation.

This patch fixes it by avoiding the digest operation and instead
doing an init followed by a final which avoids the buggy code in
shash.

This patch also ensures that the result buffer is freed after an
error so that it is not returned as a genuine hash result on the
next recv call.

The shash/ahash wrapper code will be fixed later to handle this
case correctly.

Fixes: 493b2ed3f760 ("crypto: algif_hash - Handle NULL hashes correctly")
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Comments

Laura Abbott Nov. 17, 2016, 9:20 p.m. UTC | #1
On 11/17/2016 06:07 AM, Herbert Xu wrote:
> On Wed, Nov 16, 2016 at 11:17:33AM -0800, Mat Martineau wrote:
>>
>> Herbert -
>>
>> Following commit 493b2ed3f7603a15ff738553384d5a4510ffeb95, there is a NULL
>> dereference crash in algif_hash when recv() is called twice like this:
>>
>> send(sk, data, len, MSG_MORE);
>> recv(sk, hash1, len, 0);
>> recv(sk, hash2, len, 0);
>>
>> In 4.8 and earlier, the two recvs return identical data. In 4.9-rc5, the
>> second recv triggers this:
>>
>> [   53.041287] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
>> [   53.042048] IP: [<ffffffffa73fdfb3>] shash_ahash_digest+0x23/0x130
> 
> Ugh.  It looks like the shash wrapper is incorrectly dereferencing
> the SG list even when the length is zero.  Rather than fixing it
> I'm just going to make algif_hash do the safe thing of doing an
> init followed by a final.
> 
> Thanks,
> 
> ---8<---
> Subject: crypto: algif_hash - Fix NULL hash crash with shash
> 
> Recently algif_hash has been changed to allow null hashes.  This
> triggers a bug when used with an shash algorithm whereby it will
> cause a crash during the digest operation.
> 
> This patch fixes it by avoiding the digest operation and instead
> doing an init followed by a final which avoids the buggy code in
> shash.
> 
> This patch also ensures that the result buffer is freed after an
> error so that it is not returned as a genuine hash result on the
> next recv call.
> 
> The shash/ahash wrapper code will be fixed later to handle this
> case correctly.
> 
> Fixes: 493b2ed3f760 ("crypto: algif_hash - Handle NULL hashes correctly")
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> 
> diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
> index 2d8466f..05e21b4 100644
> --- a/crypto/algif_hash.c
> +++ b/crypto/algif_hash.c
> @@ -214,23 +214,26 @@ static int hash_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
>  
>  	ahash_request_set_crypt(&ctx->req, NULL, ctx->result, 0);
>  
> -	if (ctx->more) {
> +	if (!result) {
> +		err = af_alg_wait_for_completion(
> +				crypto_ahash_init(&ctx->req),
> +				&ctx->completion);
> +		if (err)
> +			goto unlock;
> +	}
> +
> +	if (!result || ctx->more) {
>  		ctx->more = 0;
>  		err = af_alg_wait_for_completion(crypto_ahash_final(&ctx->req),
>  						 &ctx->completion);
>  		if (err)
>  			goto unlock;
> -	} else if (!result) {
> -		err = af_alg_wait_for_completion(
> -				crypto_ahash_digest(&ctx->req),
> -				&ctx->completion);
>  	}
>  
>  	err = memcpy_to_msg(msg, ctx->result, len);
>  
> -	hash_free_result(sk, ctx);
> -
>  unlock:
> +	hash_free_result(sk, ctx);
>  	release_sock(sk);
>  
>  	return err ?: len;
> 

Confirmed to work for me. You can take that as a Tested-by.

Thanks,
Laura
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
index 2d8466f..05e21b4 100644
--- a/crypto/algif_hash.c
+++ b/crypto/algif_hash.c
@@ -214,23 +214,26 @@  static int hash_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
 
 	ahash_request_set_crypt(&ctx->req, NULL, ctx->result, 0);
 
-	if (ctx->more) {
+	if (!result) {
+		err = af_alg_wait_for_completion(
+				crypto_ahash_init(&ctx->req),
+				&ctx->completion);
+		if (err)
+			goto unlock;
+	}
+
+	if (!result || ctx->more) {
 		ctx->more = 0;
 		err = af_alg_wait_for_completion(crypto_ahash_final(&ctx->req),
 						 &ctx->completion);
 		if (err)
 			goto unlock;
-	} else if (!result) {
-		err = af_alg_wait_for_completion(
-				crypto_ahash_digest(&ctx->req),
-				&ctx->completion);
 	}
 
 	err = memcpy_to_msg(msg, ctx->result, len);
 
-	hash_free_result(sk, ctx);
-
 unlock:
+	hash_free_result(sk, ctx);
 	release_sock(sk);
 
 	return err ?: len;