Fix sha512 buffer copy

[padelsbach]

Fixes F-2006 and F-2007. See related but independent wolfssl PR.

wh_Client_Sha512 unconditionally copied WC_SHA512_DIGEST_SIZE (64) bytes on finalize, regardless of SHA512 variant. For SHA512/224 (28-byte digest) and SHA512/256 (32-byte digest), this overwrites caller memory past the output buffer.

Today this is masked because the cryptocb dispatcher only handled WC_HASH_TYPE_SHA512, so variants fell through to CRYPTOCB_UNAVAILABLE and wolfSSL's software fallback handled the truncation safely. But the variants were never HSM-accelerated, and any future dispatcher fix would expose the overflow.

Changes

• Dispatcher (wh_client_cryptocb.c): Add WC_HASH_TYPE_SHA512_224 and WC_HASH_TYPE_SHA512_256 cases, routing to the same wh_Client_Sha512/wh_Client_Sha512Dma functions with info->hash.type passed through
• wh_Client_Sha512 (wh_client_crypto.c): New hashType parameter selects the correct digest size for memcpy and the correct wc_InitSha512*_ex variant for re-init
• wh_Client_Sha512Dma: Same treatment -- hashType drives digestSz, req->output.sz, and DMA post-processing size
• Tests (wh_test_crypto.c): New test cases for SHA512/224 and SHA512/256 with canary bytes to detect overwrite

Design note

The hashType parameter comes from info->hash.type, which is set by wolfSSL's cryptocb dispatch layer based on digestSz -- not from sha512->hashType, which depends on the wolfSSL port's init code setting it. This makes the fix independent of wolfSSL port behavior.

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #333

Scan targets checked: wolfhsm-consttime, wolfhsm-crypto-bugs, wolfhsm-defaults, wolfhsm-mutation, wolfhsm-proptest, wolfhsm-src, wolfhsm-zeroize

No new issues found in the changed files. ✅