PIC32MZ: give hash copies their own cached message buffer - #11394
Open
LinuxJedi wants to merge 1 commit into
Open
PIC32MZ: give hash copies their own cached message buffer#11394LinuxJedi wants to merge 1 commit into
LinuxJedi wants to merge 1 commit into
Conversation
wc_Md5Copy/wc_ShaCopy/wc_Sha256Copy shallow copy the whole hash struct and then call wc_Pic32HashCopy, which only set dst->isCopy so the shared buffer would not be freed twice. The copy therefore kept pointing at the source's storage: - With more than one block buffered the message lives in a heap buffer. An update to either context that still fits the allocation writes through the shared pointer, so the other context's message is corrupted and its digest depends on the order of operations. - Finalizing the original frees that heap buffer while the copy still references it. - With a short message the cache points at the source struct's embedded block buffer. Finalizing the original re-initializes the struct and zeroes that buffer, so the copy then hashes zeros. Deep copy the cache in wc_Pic32HashCopy instead: re-point the copy at its own embedded block buffer when the source used its own, or allocate a new heap buffer and copy the buffered bytes. Every context now owns its buffer, so the isCopy flag and the checks on it are removed. Add md5/sha/sha256 copy_update tests to wolfcrypt/test/test.c covering copy-then-update-both, copy-then-finalize-original-first and the short-message case, checked against one-shot reference digests. Reproduced and verified on the PIC32MZ simulator (EF and EC). F-10042
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
The changes address a concrete use-after-free/shared-buffer corruption issue and are backed by targeted regression tests covering the previously failing scenarios.
Pull request overview
This PR fixes a correctness and safety bug in the PIC32MZ hash “copy” path by ensuring copied MD5/SHA1/SHA256 contexts own independent cached-message buffers (instead of sharing pointers after a shallow struct copy), and adds regression tests to prevent reintroduction.
Changes:
- Reworked PIC32MZ hash cache copying to deep-copy the cached message buffer and removed the
isCopymechanism. - Updated MD5/SHA1/SHA256
*Copy()implementations to pass the standard-buffer pointers and heap hint into the PIC32MZ cache-copy helper. - Added
copy_updatetests for MD5/SHA1/SHA256 covering “copy then update both”, “finalize original first”, and “short message (embedded buffer)” scenarios.
File summaries
| File | Description |
|---|---|
| wolfssl/wolfcrypt/port/pic32/pic32mz-crypt.h | Removes isCopy from the PIC32MZ hash cache struct and updates wc_Pic32HashCopy signature to support deep-copying. |
| wolfcrypt/src/port/pic32/pic32mz-crypt.c | Implements deep-copy semantics in wc_Pic32HashCopy and removes isCopy-based free guards now that buffers are no longer shared. |
| wolfcrypt/src/md5.c | Updates wc_Md5Copy to call the new wc_Pic32HashCopy signature with src/dst standard buffers and heap hint. |
| wolfcrypt/src/sha.c | Updates wc_ShaCopy to call the new wc_Pic32HashCopy signature with src/dst standard buffers and heap hint. |
| wolfcrypt/src/sha256.c | Updates wc_Sha256Copy to call the new wc_Pic32HashCopy signature with src/dst standard buffers and heap hint. |
| wolfcrypt/test/test.c | Adds MD5/SHA1/SHA256 copy-then-update regression tests validating independent operation and correct digests after copy/final interactions. |
Review details
- Files reviewed: 6/6 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
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.
wc_Md5Copy/wc_ShaCopy/wc_Sha256Copy shallow copy the whole hash struct and then call wc_Pic32HashCopy, which only set dst->isCopy so the shared buffer would not be freed twice. The copy therefore kept pointing at the source's storage:
Deep copy the cache in wc_Pic32HashCopy instead: re-point the copy at its own embedded block buffer when the source used its own, or allocate a new heap buffer and copy the buffered bytes. Every context now owns its buffer, so the isCopy flag and the checks on it are removed.
Add md5/sha/sha256 copy_update tests to wolfcrypt/test/test.c covering copy-then-update-both, copy-then-finalize-original-first and the short-message case, checked against one-shot reference digests.
Reproduced and verified on the PIC32MZ simulator (EF and EC).
F-10042