Linux cryptographic layer development
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers3@gmail.com>
To: Li Kun <hw.likun@huawei.com>
Cc: linux-crypto@vger.kernel.org
Subject: Re: [PATCH RESEND] crypto: af_alg - add keylen checking to avoid NULL ptr passing down
Date: Mon, 18 Dec 2017 11:12:33 -0800	[thread overview]
Message-ID: <20171218191233.GA55142@gmail.com> (raw)
In-Reply-To: <1513604436-43814-1-git-send-email-hw.likun@huawei.com>

On Mon, Dec 18, 2017 at 01:40:36PM +0000, Li Kun wrote:
> alg_setkey do not check the keylen whether it is zero, so the key
> may be ZERO_SIZE_PTR when keylen is 0, which will pass the
> copy_from_user's checking and be passed to the lower functions as key.
> 
> If the lower functions only check the key if it is NULL, ZERO_SIZE_PTR
> will pass the checking, and will cause null ptr dereference, so it's
> better to intercept the invalid parameters in the upper functions.
> 
> This patch is also suitable to fix CVE-2017-15116 for stable trees.
> 
> Signed-off-by: Li Kun <hw.likun@huawei.com>
> Cc: stable@vger.kernel.org
> ---
>  crypto/af_alg.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/crypto/af_alg.c b/crypto/af_alg.c
> index 337cf38..10f22f3 100644
> --- a/crypto/af_alg.c
> +++ b/crypto/af_alg.c
> @@ -210,6 +210,8 @@ static int alg_setkey(struct sock *sk, char __user *ukey,
>  	u8 *key;
>  	int err;
>  
> +	if (!keylen)
> +		return -EINVAL;
>  	key = sock_kmalloc(sk, keylen, GFP_KERNEL);
>  	if (!key)
>  		return -ENOMEM;
> -- 

If the length is 0 then why is the underlying ->setkey() method dereferencing
the pointer?  Which algorithm does this happen for?  Checking for NULL makes no
sense; the length needs to be checked instead.

Eric

  reply	other threads:[~2017-12-18 19:12 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-18 13:40 [PATCH RESEND] crypto: af_alg - add keylen checking to avoid NULL ptr passing down Li Kun
2017-12-18 19:12 ` Eric Biggers [this message]
2017-12-19  1:19   ` Li Kun

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=20171218191233.GA55142@gmail.com \
    --to=ebiggers3@gmail.com \
    --cc=hw.likun@huawei.com \
    --cc=linux-crypto@vger.kernel.org \
    /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