linux-kernel - [PATCH 5/8] crypto: api - always set CRYPTO_ALG

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-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20211003181413.12465-6-nstange@suse.de>
Date:   Sun,  3 Oct 2021 20:14:10 +0200
From:   Nicolai Stange <nstange@...e.de>
To:     Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>
Cc:     linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
        Stephan Müller <smueller@...onox.de>,
        Torsten Duwe <duwe@...e.de>, Nicolai Stange <nstange@...e.de>
Subject: [PATCH 5/8] crypto: api - always set CRYPTO_ALG_TESTED in lookup larvals' ->mask/type

For crypto_alg_lookup(), the input parameter combination of mask and type
where both have CRYPTO_ALG_TESTED unset is special in that it is supposed
to be handled as if said flag had been set in both for convenience.

However, the code in crypto_alg_lookup() is not equivalent between these
two cases:
- If CRYPTO_ALG_TESTED is unset in both type and mask, a pending
  lookup larval with or without ->CRYPTO_ALG_TESTED being set in its
  ->mask and ->type can potentially get returned, whereas if
  CRYPTO_ALG_TESTED is set in both, only the former is possible.
- If CRYPTO_ALG_TESTED is unset in both type and mask, an error would get
  returned if there was one or more matching algorithms which all had
  failed their selftests. If OTOH CRYPTO_ALG_TESTED had been set in both
  type and mask, NULL would get returned in this case of universal failure
  and the caller would proceed to re-request the algorithm in question,
  which is not desired.

Even though the first issue is only a cosmetic one and does not affect
functionality in any way AFAICT, addressing it with this patch here will
improve consistency and allow for streamlining crypto_alg_lookup() a bit
later in this series. The second item in the list from above will be left
to a later patch.

Remember that crypto_larval_lookup() will only invoke crypto_larval_add()
if CRYPTO_ALG_TESTED has been set in either none or both of mask and type.
Make crypto_larval_lookup() always set CRYPTO_ALG_TESTED for the mask
and type values passed to crypto_larval_add(). That is, the "issue"
described above is being addressed by sticking to a canonical lookup larval
representation for the two equivalent cases.

There is no change in functionality.

Signed-off-by: Nicolai Stange <nstange@...e.de>
---
 crypto/api.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/crypto/api.c b/crypto/api.c
index 3bee52d7fe4b..71406f486c65 100644
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -284,17 +284,17 @@ static struct crypto_alg *crypto_larval_lookup(const char *name, u32 type,
 	if (!IS_ERR_OR_NULL(alg) && crypto_is_larval(alg))
 		alg = crypto_larval_wait(alg);
 	else if (!alg) {
+		if (!(mask & CRYPTO_ALG_TESTED)) {
+			WARN_ON_ONCE((type & CRYPTO_ALG_TESTED));
+			mask |= CRYPTO_ALG_TESTED;
+			type |= CRYPTO_ALG_TESTED;
+		}
+
 		/*
 		 * Only add a lookup larval if the request is for a
 		 * tested algorithm, everything else makes no sense.
 		 */
-		bool tested = type & mask & CRYPTO_ALG_TESTED;
-
-		if (!(mask & CRYPTO_ALG_TESTED)) {
-			WARN_ON_ONCE((type & CRYPTO_ALG_TESTED));
-			tested = true;
-		}
-		if (tested)
+		if (type & CRYPTO_ALG_TESTED)
 			alg = crypto_larval_add(name, type, mask);
 		else
 			alg = ERR_PTR(-ENOENT);
-- 
2.26.2