linux-kernel - [BUG 2/2] crypto: ahash - testmgr false failures with CRYPTO_AHASH_ALG_BLOCK

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] [day] [month] [year] [list]
Message-ID: <20251113140634.1559529-3-t-pratham@ti.com>
Date: Thu, 13 Nov 2025 19:30:13 +0530
From: T Pratham <t-pratham@...com>
To: <t-pratham@...com>, Herbert Xu <herbert@...dor.apana.org.au>, "David S.
 Miller" <davem@...emloft.net>
CC: <linux-crypto@...r.kernel.org>, <linux-kernel@...r.kernel.org>, "Manorit
 Chawdhry" <m-chawdhry@...com>, Shiva Tripathi <s-tripathi1@...com>
Subject: [BUG 2/2] crypto: ahash - testmgr false failures with CRYPTO_AHASH_ALG_BLOCK_ONLY

Hi,

Commit 9d7a0ab1c7536 ("crypto: ahash - Handle partial blocks in API")
introduced partial block handling for ahashes in the crypto API layer itself.
This enables ahash algorithms to return a positive integer from the update
function to indicate the number of bytes in the input which are not processed
and should be buffered for next update/finup/final call to process.

It appears that the testmgr is not updated to handle this positive return value
from update(). As a result, self-tests fail (falsely) for such ahash
algorithms. Below are dmesg logs from my (work-in-progress) TI dthev2 hash
driver:

[   12.933924] alg: ahash: sha256-dthev2 update() failed with err 62 on test vector 4, cfg="init+update+final aligned buffer"
[   12.951212] alg: self-tests for sha256 using sha256-dthev2 failed (rc=62)
[   13.008108] alg: self-tests for sha256 using sha256-dthev2 failed (rc=62)
[   13.361625] alg: ahash: sha512-dthev2 update() failed with err 126 on test vector 5, cfg="init+update+final aligned buffer"
[   13.376311] alg: self-tests for sha512 using sha512-dthev2 failed (rc=126)
[   13.388088] alg: self-tests for sha512 using sha512-dthev2 failed (rc=126)
[   13.389503] alg: ahash: md5-dthev2 update() failed with err 15 on test vector 6, cfg="init+update+final aligned buffer"
[   13.421488] alg: self-tests for md5 using md5-dthev2 failed (rc=15)
[   13.478062] alg: self-tests for md5 using md5-dthev2 failed (rc=15)

Note: the driver works completely fine on a TI internal v6.12 LTS tree where
this buffering is being handled by the driver itself.

Now, while debugging the issue, this messy fixup in testmgr code works fine and
my ahash driver passes.

diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 6a490aaa71b9a..523507e79f760 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -34,6 +34,7 @@
 #include <crypto/kpp.h>
 #include <crypto/acompress.h>
 #include <crypto/sig.h>
+#include <crypto/internal/hash.h>
 #include <crypto/internal/cipher.h>
 #include <crypto/internal/simd.h>
 
@@ -1571,9 +1572,16 @@ static int test_ahash_vec_cfg(const struct hash_testvec *vec,
                                                pending_len);
                        err = do_ahash_op(crypto_ahash_update, req, &wait,
                                          divs[i]->nosimd);
-                       err = check_nonfinal_ahash_op("update", err,
-                                                     result, digestsize,
-                                                     driver, vec_name, cfg);
+                       if ((crypto_ahash_alg(tfm)->halg.base.cra_flags &
+                           CRYPTO_AHASH_ALG_BLOCK_ONLY) &&
+                           err >= 0)
+                               err = check_nonfinal_ahash_op("update", 0,
+                                                             result, digestsize,
+                                                             driver, vec_name, cfg);
+                       else
+                               err = check_nonfinal_ahash_op("update", err,
+                                                             result, digestsize,
+                                                             driver, vec_name, cfg);
                        if (err)
                                return err;
                        pending_sgl = NULL;
@@ -1614,8 +1622,14 @@ static int test_ahash_vec_cfg(const struct hash_testvec *vec,
        if (cfg->finalization_type == FINALIZATION_TYPE_FINAL) {
                /* finish with update() and final() */
                err = do_ahash_op(crypto_ahash_update, req, &wait, cfg->nosimd);
-               err = check_nonfinal_ahash_op("update", err, result, digestsize,
-                                             driver, vec_name, cfg);
+               if ((crypto_ahash_alg(tfm)->halg.base.cra_flags &
+                   CRYPTO_AHASH_ALG_BLOCK_ONLY) &&
+                   err >= 0)
+                       err = check_nonfinal_ahash_op("update", 0, result, digestsize,
+                                                     driver, vec_name, cfg);
+               else
+                       err = check_nonfinal_ahash_op("update", err, result, digestsize,
+                                                     driver, vec_name, cfg);
                if (err)
                        return err;
                err = do_ahash_op(crypto_ahash_final, req, &wait, cfg->nosimd);

While I have not tested any shash code with CRYPTO_AHASH_ALG_BLOCK_ONLY, it is
highly possible that testmgr will report a false negative there as well.

I can send a fix for ahash. Let me know if it is better to just add a separate
check in the testmgr (in which case, I'll cleanup the above diff and send as a
separate patch), or should we modify the crypto_ahash_update() function in
crypto/ahash.c to return 0 as it handles all the buffer management inside
itself. The callers of crypto_ahash_update() anyway don't expect a non-zero
positive value on success as far as I can see. 

-- 
Regards
T Pratham <t-pratham@...com>