linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: "Stephan Müller" <smueller@chronox.de>
Cc: <herbert@gondor.apana.org.au>,
	syzbot 
	<bot+3cbaad7926415bb8cfce88469e5f66a2bbd0d0cd@syzkaller.appspotmail.com>,
	<davem@davemloft.net>, <linux-crypto@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <syzkaller-bugs@googlegroups.com>
Subject: Re: [PATCH] crypto: AF_ALG - fix race accessing cipher request
Date: Fri, 8 Dec 2017 11:39:06 +0000	[thread overview]
Message-ID: <20171208113906.000050aa@huawei.com> (raw)
In-Reply-To: <5543369.6UIL7PonCy@positron.chronox.de>

On Fri, 8 Dec 2017 11:50:37 +0100
Stephan Müller <smueller@chronox.de> wrote:

> Hi Herbert,
> 
> This patch would go on top of 7d2c3f54e6f646887d019faa45f35d6fe9fe82ce
> "crypto: af_alg - remove locking in async callback" found in Linus' tree
> which is not yet in the cryptodev-2.6 tree.
> 
> In addition, this patch is already on top of the other patches discussed
> on this list fixing similar issues. I.e. depending in which order you apply
> the patches, there may be a hunk. In case you want me to rebase the patch,
> please let me know.
> 
> ---8<---
> When invoking an asynchronous cipher operation, the invocation of the
> callback may be performed before the subsequent operations in the
> initial code path are invoked. The callback deletes the cipher request
> data structure which implies that after the invocation of the
> asynchronous cipher operation, this data structure must not be accessed
> any more.
> 
> The setting of the return code size with the request data structure must
> therefore be moved before the invocation of the asynchronous cipher
> operation.
> 
> Fixes: e870456d8e7c ("crypto: algif_skcipher - overhaul memory management")
> Fixes: d887c52d6ae4 ("crypto: algif_aead - overhaul memory management")
> Reported-by: syzbot <syzkaller@googlegroups.com>
> Cc: <stable@vger.kernel.org> # v4.14+
> Signed-off-by: Stephan Mueller <smueller@chronox.de>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Have an identical patch in my queue having observed this happening on our
hardware - though only had the skcipher case.

As a heads up, the other nasties we've found so far are around hitting limits
on the various socket buffers.  When you run into those you can end up with
parts of the data to be encrypted going through without it being obvious.

Will update on that properly once I've chased down a local problem that
is limiting the length of my test runs to a few million messages.

Jonathan

> ---
>  crypto/algif_aead.c     | 10 +++++-----
>  crypto/algif_skcipher.c | 10 +++++-----
>  2 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
> index 15e561dc47b5..d7ec2f4ebaf9 100644
> --- a/crypto/algif_aead.c
> +++ b/crypto/algif_aead.c
> @@ -291,6 +291,10 @@ static int _aead_recvmsg(struct socket *sock, struct msghdr *msg,
>  		/* AIO operation */
>  		sock_hold(sk);
>  		areq->iocb = msg->msg_iocb;
> +
> +		/* Remember output size that will be generated. */
> +		areq->outlen = outlen;
> +
>  		aead_request_set_callback(&areq->cra_u.aead_req,
>  					  CRYPTO_TFM_REQ_MAY_BACKLOG,
>  					  af_alg_async_cb, areq);
> @@ -298,12 +302,8 @@ static int _aead_recvmsg(struct socket *sock, struct msghdr *msg,
>  				 crypto_aead_decrypt(&areq->cra_u.aead_req);
>  
>  		/* AIO operation in progress */
> -		if (err == -EINPROGRESS || err == -EBUSY) {
> -			/* Remember output size that will be generated. */
> -			areq->outlen = outlen;
> -
> +		if (err == -EINPROGRESS || err == -EBUSY)
>  			return -EIOCBQUEUED;
> -		}
>  
>  		sock_put(sk);
>  	} else {
> diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
> index 6fb595cd63ac..baef9bfccdda 100644
> --- a/crypto/algif_skcipher.c
> +++ b/crypto/algif_skcipher.c
> @@ -125,6 +125,10 @@ static int _skcipher_recvmsg(struct socket *sock, struct msghdr *msg,
>  		/* AIO operation */
>  		sock_hold(sk);
>  		areq->iocb = msg->msg_iocb;
> +
> +		/* Remember output size that will be generated. */
> +		areq->outlen = len;
> +
>  		skcipher_request_set_callback(&areq->cra_u.skcipher_req,
>  					      CRYPTO_TFM_REQ_MAY_SLEEP,
>  					      af_alg_async_cb, areq);
> @@ -133,12 +137,8 @@ static int _skcipher_recvmsg(struct socket *sock, struct msghdr *msg,
>  			crypto_skcipher_decrypt(&areq->cra_u.skcipher_req);
>  
>  		/* AIO operation in progress */
> -		if (err == -EINPROGRESS || err == -EBUSY) {
> -			/* Remember output size that will be generated. */
> -			areq->outlen = len;
> -
> +		if (err == -EINPROGRESS || err == -EBUSY)
>  			return -EIOCBQUEUED;
> -		}
>  
>  		sock_put(sk);
>  	} else {

  reply	other threads:[~2017-12-08 11:39 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-04 15:57 KASAN: use-after-free Write in aead_recvmsg syzbot
2017-12-08 10:50 ` [PATCH] crypto: AF_ALG - fix race accessing cipher request Stephan Müller
2017-12-08 11:39   ` Jonathan Cameron [this message]
2017-12-08 12:43     ` AF_ALG: skb limits Stephan Mueller
2017-12-12 13:59       ` Jonathan Cameron
2018-01-13 14:04         ` Stephan Müller
2018-01-15  9:46           ` Jonathan Cameron
2017-12-11 11:52   ` [PATCH] crypto: AF_ALG - fix race accessing cipher request Herbert Xu
2017-12-11 19:03 ` KASAN: use-after-free Write in aead_recvmsg Eric Biggers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171208113906.000050aa@huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=bot+3cbaad7926415bb8cfce88469e5f66a2bbd0d0cd@syzkaller.appspotmail.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=smueller@chronox.de \
    --cc=syzkaller-bugs@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).