[danielinux]

Description

Summary

Fix heap allocation alignment for Aes contexts used by wc_AesNew and the small-stack AES key-wrap wrappers.

Root cause

The reported armhf SIGBUS was initially attributed to _sp_div because the runtime PC was translated using the executable’s file offset. This PIE executable’s text virtual address is 0x10000 higher than that offset. Correcting the translation places the fault in wc_AesSetKeyLocal, at a NEON store to aes->reg that requires 16-byte alignment.

The fault address was only 8-byte aligned. Aes has 16-byte-aligned members, but XMALLOC can return an 8-byte-aligned pointer on 32-bit Arm. Passing that pointer as an Aes* lets the compiler emit an alignment-qualified store that faults.

Changes

• Add an AES allocation helper that aligns the returned context to WC_ALIGNOF(Aes) when WOLFSSL_USE_ALIGN is enabled. It retains the original XMALLOC pointer so the matching free uses the correct address, heap, and allocation type.
• Use the helper in wc_AesNew and the four small-stack AES key-wrap and unwrap wrappers, including the padded variants.
• Add a constructor alignment check to the AES test and update a test comment.

The helper applies wherever alignment is enabled, regardless of architecture or assembly settings. Builds without WOLFSSL_USE_ALIGN continue to use ordinary XMALLOC and XFREE. The Aes structure layout is unchanged.

Relationship to #11949

PR 11949 adds general aligned-allocation APIs, but it does not switch wc_AesNew or the AES key-wrap wrappers to those APIs. It converts one test helper that already aligned its allocation manually. Merging PR 11949 alone therefore leaves the faulting allocations unchanged. If PR 11949 lands first, this change could use its XMALLOCALIGN/XFREEALIGN pair instead of the local helper; the AES callers still need to be updated.

Validation

• GCC small-stack AES key-wrap build: wolfCrypt test suite passed.
• Clang small-stack AES key-wrap build, including padded key wrap: wolfCrypt test suite passed.
• Clang smoke test with an allocator deliberately returning 8-byte-aligned memory: AES construction, key setup, wrap, and unwrap passed.

Tracking

• Fixes F-11986

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.

[github-actions]

MemBrowse Memory Report · Explore what changed →

No memory changes detected for:

• gcc-arm-cortex-m0plus
• gcc-arm-cortex-m3
• gcc-arm-cortex-m4
• gcc-arm-cortex-m4-baremetal
• gcc-arm-cortex-m4-crypto-only
• gcc-arm-cortex-m4-dtls13
• gcc-arm-cortex-m4-min-ecc
• gcc-arm-cortex-m4-openssl-compat
• gcc-arm-cortex-m4-pkcs7
• gcc-arm-cortex-m4-pq
• gcc-arm-cortex-m4-rsa-only
• gcc-arm-cortex-m4-sp-math
• gcc-arm-cortex-m4-tls12
• gcc-arm-cortex-m4-tls13
• gcc-arm-cortex-m7
• gcc-arm-cortex-m7-pq
• gcc-arm-cortex-m7-tls13
• stm32-sim-stm32h753
• zephyr-frdm_rw612

---

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

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #12110

Scan targets checked: wolfcrypt-src, wolfcrypt-bugs
Coverage: 2 of 2 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]

Fenrir Automated Review — PR #12110

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

Fenrir result: Approved ✅

No new issues found in the changed files.

Advisory only — this automated result does not count as a GitHub approval.

Review tier: Lite

Fenrir's latest completed scan found no issues; clearing the prior automated change request.

[philljj]

@claude review

[claude]

Beyond the inline findings, I also checked the pointer arithmetic in AesAlloc/AesAllocFree and found no problem with it. Rounding raw + sizeof(void*) up leaves room for the stored base pointer. The Aes object fits in the extra align - 1 + sizeof(void*) bytes. The base-pointer slot is pointer-aligned. The key-wrap allocation-failure paths return before reaching out:, so they never free a NULL aes.

Extended reasoning...

I checked the AesAlloc/AesAllocFree pointer arithmetic and the key-wrap small-stack cleanup paths in wolfcrypt/src/aes.c and found no problem in either. The inline comments already cover the open problems.

Findings marked 🟡 are optional suggestions and need no follow-up push.