[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <08384a82-8b41-69e0-ad04-705f011ed92a@infradead.org>
Date: Mon, 29 Mar 2021 21:11:17 -0700
From: Randy Dunlap <rdunlap@...radead.org>
To: Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
Dexuan Cui <decui@...rosoft.com>,
Eric Biggers <ebiggers@...nel.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
Herbert Xu <herbert@...dor.apana.org.au>
Subject: crypto: possible NULL reference
As I was trying to document "fips=<integer", I noticed this.
In crypto/ecc.c, ecc_get_curve() can return NULL:
const struct ecc_curve *ecc_get_curve(unsigned int curve_id)
{
switch (curve_id) {
/* In FIPS mode only allow P256 and higher */
case ECC_CURVE_NIST_P192:
return fips_enabled ? NULL : &nist_p192;
case ECC_CURVE_NIST_P256:
return &nist_p256;
case ECC_CURVE_NIST_P384:
return &nist_p384;
default:
return NULL;
}
}
but when its return value is passed to
static int __ecc_is_key_valid(const struct ecc_curve *curve,
const u64 *private_key, unsigned int ndigits)
the use of <curve> here is not checked for NULL or not NULL
before it is used. Nor is the use of <curve> in most other functions
in ecc.c.
Is there something else protecting the improper use of <curve>
in these cases? or is a patch warranted?
thanks.
--
~Randy
Powered by blists - more mailing lists