[JacobBarthelmeh]

No description provided.

[github-actions]

MemBrowse Memory Report · Explore what changed →

gcc-arm-cortex-m0plus

• FLASH: .text +8 B (+0.0%, 70,719 B / 262,144 B, total: 27% used)

gcc-arm-cortex-m3

• FLASH: .text +204 B (+0.2%, 131,693 B / 262,144 B, total: 50% used)

gcc-arm-cortex-m4

• FLASH: .text +348 B (+0.2%, 208,972 B / 262,144 B, total: 80% used)

gcc-arm-cortex-m4-baremetal

• FLASH: .text +64 B (+0.1%, 73,463 B / 262,144 B, total: 28% used)

gcc-arm-cortex-m4-crypto-only

• FLASH: .text -64 B (-0.0%, 181,651 B / 262,144 B, total: 69% used)

gcc-arm-cortex-m4-dtls13

• FLASH: .text +448 B (+0.2%, 195,928 B / 1,048,576 B, total: 19% used)

gcc-arm-cortex-m4-openssl-compat

• FLASH: .rodata +2,464 B, .text +64 B (+0.3%, 800,676 B / 1,048,576 B, total: 76% used)
• RAM: .bss -12,048 B (-9.0%, 121,772 B / 262,144 B, total: 46% used)

gcc-arm-cortex-m4-pkcs7

• FLASH: .text -64 B (-0.0%, 222,740 B / 262,144 B, total: 85% used)

gcc-arm-cortex-m4-pq

• FLASH: .text +640 B (+0.2%, 312,784 B / 1,048,576 B, total: 30% used)

gcc-arm-cortex-m4-rsa-only

• FLASH: .rodata +8 B, .text +832 B (+0.2%, 343,632 B / 1,048,576 B, total: 33% used)
• RAM: .bss +1,320 B (+7.9%, 17,996 B / 262,144 B, total: 7% used)

gcc-arm-cortex-m4-tls12

• FLASH: .text +192 B (+0.1%, 132,433 B / 262,144 B, total: 51% used)

gcc-arm-cortex-m4-tls13

• FLASH: .text +384 B (+0.2%, 249,506 B / 262,144 B, total: 95% used)

gcc-arm-cortex-m7

• FLASH: .text +284 B (+0.1%, 208,972 B / 262,144 B, total: 80% used)

gcc-arm-cortex-m7-pq

• FLASH: .text +576 B (+0.2%, 313,616 B / 1,048,576 B, total: 30% used)

gcc-arm-cortex-m7-tls13

• FLASH: .text +384 B (+0.2%, 249,506 B / 262,144 B, total: 95% used)

zephyr-frdm_rw612

• FLASH: text +24 B (+0.0%, 284,040 B / 67,108,864 B, total: 0% used)

No memory changes detected for:

• gcc-arm-cortex-m4-min-ecc
• gcc-arm-cortex-m4-sp-math
• stm32-sim-stm32h753

---

_{Catch memory regressions in CI with MemBrowse. Free for open source.}

[Copilot]

🟡 Changes recommended

Process-global error snapshots still permit data races and mismatched diagnostics, while new test assertions fail in Windows debug/OpenSSL-extra builds with the error queue disabled.

2 open issues

• Guard error-queue assertions when the queue is disabled · New
• Global error snapshots can race after the queue lock is released · New

What changed in this PR

This PR hardens wolfSSL’s error-queue handling and cryptographic internals by addressing stale pointers, removing data-dependent branches, and clearing temporary key material.

Changes:

• Copy exported error strings, reset queue cursors during cleanup, and add regression tests.
• Replace conditional XOR operations with masking in GCM and GCM-SIV multiplication paths.
• Zero temporary key material after ColdFire DES operations.

File	Description
wolfcrypt/​src/​logging.c	Adds error-string snapshots and resets cursors when clearing queues.
wolfcrypt/​src/​des3.c	Clears the ColdFire DES temporary key buffer.
wolfcrypt/​src/​aes.c	Uses branchless masking in selected multiplication paths.
tests/​api.c	Adds queue-reset and returned-string lifetime checks.

_{Review effort: Balanced}

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #12001

Scan targets checked: wolfcrypt-src, wolfcrypt-bugs, wolfssl-bugs
Coverage: 4 of 4 in-scope changed file(s) opened by the reviewer

Findings: 1
1 finding(s) posted as inline comments (see file-level comments below)

This review was generated automatically by Fenrir. Reported findings require changes before merge.

Review tier: Max

[wolfSSL-Fenrir-bot]

Error-queue string buffers are shared between threads when THREAD_LS_T is empty · Race conditions

In the mutex-protected global queue, wc_errq_file and wc_errq_reason become ordinary shared globals wherever THREAD_LS_T is empty: no HAVE_THREAD_LS, NO_THREAD_LS, FreeRTOS, Zephyr, or the kernel builds that #undef HAVE_THREAD_LS. They are written under the queue lock, but callers read them after ERRQ_UNLOCK(). Another thread's peek or pull can then overwrite the strings mid-read. Before this PR, peek and pull did not cause that.

Suggested fix: Fixing this for builds without working thread-local storage needs a design decision (caller-owned buffers, or requiring real TLS); see C11 §5.1.2.4 on data races.

Related known findings (similar but distinct; listed for context, not part of this finding)

• F-9964: F-9964 is a use-after-free through pointers into heap nodes. This PR swaps that storage for buffers that are only thread-local when TLS works, so non-TLS multi-threaded builds now race on every concurrent peek or pull.