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
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.