Fixes for AES in Octeon and TI

[dgarske]

F-8251 - Octeon non-12-byte GCM IV is hashed before GHASH initialization

Octeon_AesGcm_SetIV() fed a non-12-byte IV to the GFM unit before Octeon_GHASH_Init() loaded aes->gcm.H and cleared the result registers, so J0 was derived against leftover hardware state from the previous operation. Now initializes GHASH before hashing the IV; the existing init after the IV hash still resets state for the AAD/ciphertext passes.

Also folded in here: aes->H -> aes->gcm.H. That member moved into the nested Gcm sub-struct in e2424e6 (SM2/SM3/SM4) and the port has not compiled since.

F-8237 - Octeon AES-GCM decryption overwrites rather than verifies the authentication tag

Octeon_AesGcm_Finalize() stored the computed tag straight through the caller's tag pointer, and Octeon_AesGcm_Decrypt() used that same path, so myCryptoDevCb() handed it the peer's tag and it got clobbered instead of checked. Any forged tag was accepted once wc_CryptoCb_InitOcteon() was registered.

Both directions now finalize into a private ALIGN16 block. Decrypt compares authTagSz bytes with ConstantCompare(), returns AES_GCM_AUTH_E on mismatch, ForceZero()s the plaintext output, and never writes through the caller's tag pointer. Encrypt copies only authTagSz bytes out, which also fixes an overflow: it previously wrote a full 16 bytes even though wc_local_AesGcmCheckTagSz() permits truncated tags. authTagSz is now threaded through both callback paths.

F-8253 - TI authenticated AES checks lengths instead of pointer alignment

AesAuthEncrypt()/AesAuthDecrypt() applied IS_ALIGN16() - an address test - to inSz and authInSz. When a length happened to be a multiple of 16, the caller's in, out and authIn pointers went to ROM_AESDataProcessAuth() as unsigned int* at whatever byte alignment they actually had; out was never checked or bounced on its own at all.

Alignment and length are now separate concerns: IS_ALIGN16() tests addresses (via wc_ptr_t, so it no longer truncates), and a new IS_MULT16() tests lengths. in, out and authIn each get an independent bounce buffer when either their address is unaligned or the length is not a whole number of blocks. The out write-back is guarded so it is not a self-copy when out was not bounced.

[Copilot]

Pull request overview

This PR fixes correctness and safety issues in hardware-accelerated AES-GCM/CCM paths for Cavium Octeon and TI, aligning behavior with wolfSSL’s software expectations (fresh GHASH state, tag verification vs overwrite, correct handling of truncated tags, and correct buffer alignment/size handling for TI ROM APIs).

Changes:

• Octeon AES-GCM: initialize GHASH state before hashing non-12-byte IVs; use aes->gcm.H; compute tags into a private buffer and verify tags on decrypt (zeroing plaintext on failure).
• Octeon AES-GCM: thread authTagSz through callback paths and only copy tagSz bytes to the caller (fixing truncated-tag overflow).
• TI AES auth modes: separate pointer-alignment checks from length (block-multiple) checks and bounce in/out/authIn independently when needed.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
wolfcrypt/src/port/ti/ti-aes.c	Fixes TI ROM authenticated AES buffer handling by correctly distinguishing alignment vs length constraints and bouncing buffers safely.
wolfcrypt/src/port/cavium/cavium_octeon_sync.c	Fixes Octeon AES-GCM GHASH initialization ordering and correct tag handling (no overwrite on decrypt, supports truncated tags safely).

Suppressed comments (1)

wolfcrypt/src/port/cavium/cavium_octeon_sync.c:782

• Tag length validation here accepts any 1..16 bytes, but wolfSSL only permits specific AES-GCM tag sizes depending on WOLFSSL_MIN_AUTH_TAG_SZ (via wc_local_AesGcmCheckTagSz). This decrypt path should reject unsupported sizes consistently with the software implementation.

    if (aes == NULL || tag == NULL || tagSz == 0 ||
            tagSz > WC_AES_BLOCK_SIZE) {
        ret = BAD_FUNC_ARG;
    }

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

MemBrowse Memory Report

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
• linuxkm-pie
• linuxkm-standard
• stm32-sim-stm32h753

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #11148

Scan targets checked: wolfcrypt-port-bugs

No new issues found in the changed files. ✅