linux-kernel - crypto: possible NULL reference

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]

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