lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ