Skip to content

PIC32MZ: give hash copies their own cached message buffer - #11394

Open
LinuxJedi wants to merge 1 commit into
wolfSSL:masterfrom
LinuxJedi:pic32-hash-copy-deep-copy
Open

PIC32MZ: give hash copies their own cached message buffer#11394
LinuxJedi wants to merge 1 commit into
wolfSSL:masterfrom
LinuxJedi:pic32-hash-copy-deep-copy

Conversation

@LinuxJedi

Copy link
Copy Markdown
Member

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

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
Copilot AI lite review requested due to automatic review settings September 7, 2026 15:33

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 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 isCopy mechanism.
  • Updated MD5/SHA1/SHA256 *Copy() implementations to pass the standard-buffer pointers and heap hint into the PIC32MZ cache-copy helper.
  • Added copy_update tests 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.

@github-actions

github-actions Bot commented Sep 7, 2026

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants