Hash: consistent error code for uninitialized wc_Hash ops under DEBUG_WOLFSSL#10927
Merged
JacobBarthelmeh merged 1 commit intoJul 16, 2026
Merged
Conversation
Under DEBUG_WOLFSSL the hash->type != type check in wc_HashUpdate, wc_HashFinal and wc_HashFree fired for an uninitialized hash (hash->type == WC_HASH_TYPE_NONE), returning BAD_FUNC_ARG where a non-debug build returns HASH_TYPE_E from the type switch, so the returned error code depended on whether DEBUG_WOLFSSL was defined. Only apply the mismatch check to initialized hashes; the genuine init-then-wrong-type misuse check is preserved.
Contributor
There was a problem hiding this comment.
Pull request overview
This PR makes wc_HashUpdate, wc_HashFinal, and wc_HashFree return consistent error codes under DEBUG_WOLFSSL when the wc_HashAlg object is uninitialized (hash->type == WC_HASH_TYPE_NONE). It ensures the debug-only “type mismatch” guard only applies after the hash has been initialized, aligning debug builds with non-debug behavior for this case.
Changes:
- Gate the
DEBUG_WOLFSSLtype-mismatch check onhash->type != WC_HASH_TYPE_NONEinwc_HashUpdate. - Apply the same gating in
wc_HashFinal. - Apply the same gating in
wc_HashFree.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
danielinux
added a commit
to danielinux/wolfssl
that referenced
this pull request
Jul 16, 2026
Under DEBUG_WOLFSSL, wc_HashUpdate/Final/Free first check (hash->type != type) and return BAD_FUNC_ARG before the switch, so the "unsupported type -> HASH_TYPE_E" arm is unreachable on an uninitialized hash (wc_HashInit refuses those types). Guard those Update/Final/Free assertions with #ifndef DEBUG_WOLFSSL; the arm's coverage comes from non-DEBUG variants in the union. Fixes the cmake (old-TLS/debug) build failure. wc_HashInit assertions keep running (Init has no such type check). This bug is fixed in PR wolfSSL#10927
Member
Author
|
Jenkins retest this please |
JacobBarthelmeh
approved these changes
Jul 16, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Under DEBUG_WOLFSSL the hash->type != type check in wc_HashUpdate, wc_HashFinal and wc_HashFree fired for an uninitialized hash (hash->type == WC_HASH_TYPE_NONE), returning BAD_FUNC_ARG where a non-debug build returns HASH_TYPE_E from the type switch, so the returned error code depended on whether DEBUG_WOLFSSL was defined. Only apply the mismatch check to initialized hashes; the genuine init-then-wrong-type misuse check is preserved.
Testing
Discovered via MC/DC campaign part 3 #10912