The little-endian large-code path of mlkem_vec_compress_10_c cast the
output byte buffer to word32* and issued five 32-bit stores through it.
That buffer is the caller-supplied ML-KEM ciphertext, which has no
alignment guarantee, so on strict-alignment targets the store bus-faults
and the cast violates strict aliasing. Write each word with
writeUnalignedWord32, which does an alignment-safe byte copy, matching
mldsa_encode_w1_88_c and the neighboring ML-KEM sampling code.
Fixes F-6782.
The little-endian large-code path of mlkem_cbd_eta3 cast the
caller-supplied byte buffer to word32* and read through it. The buffer
has no alignment guarantee, so on strict-alignment targets such as
Cortex-M3 and M4 with unaligned-access trapping enabled the read faults
or returns wrong values, and the cast violates strict aliasing. Read
each word with readUnalignedWord32, which does an alignment-safe byte
copy, matching the neighboring mlkem_cbd_eta2.
Fixes F-6781.
wc_InitRsaKey_Id cast the byte array key->id to word32* and dereferenced
it to recover the SE050 key id. key->id is a byte array with no alignment
guarantee inside RsaKey, so the dereference is an unaligned 32-bit read
that faults or mis-reads on strict-alignment targets, and it violates
strict aliasing. Read the value with readUnalignedWord32 instead, which
does an alignment-safe byte copy, matching wc_ecc_init_id.
Fixes F-6624.
The ESP32-C3 deactivation path in esp_mp_hw_unlock passed its arguments
to DPORT_REG_CLR_BIT and DPORT_REG_SET_BIT in the wrong order and added
a stray DR_REG_RSA_BASE offset. The macros take (register address, bit
mask), but the code used the bit mask as part of the register address
and the register as the bit mask. As a result the RSA clock-enable and
memory power-down bits were never updated at deactivation, and reads and
writes landed at a bogus peripheral address. The accelerator was left
powered up after every bignum and RSA operation.
Pass the register address first and the bit mask second and drop the
offset, mirroring the activation path and the other targets.
Fixes F-6779.
IntelQaSymCipher ran cpaCySymPerformOp synchronously but never
translated its completion status into the return code. Only the AES-GCM
decrypt auth check, driven by verifyResult, could set an error. For
AES-CBC, AES-GCM encrypt, and 3DES-CBC a non-success status left ret at
zero, so the exit path copied the working buffer to the output and
returned success. On encrypt that buffer still holds the plaintext copy,
so a hardware failure returned success with plaintext written to the
ciphertext output.
Translate a non-success perform-op status into ASYNC_OP_E, matching the
asynchronous port, so hardware failures are surfaced instead of
returning zero with unprocessed output.
Fixes F-6623.
wc_DhSetKey_ex loads DH parameters as untrusted and validates that the
modulus is prime, but it passed no RNG, so the check fell back to a
Miller-Rabin test using the fixed small-prime bases 2 through 19. That
test is defeatable: a composite crafted as a strong pseudoprime to those
known bases passes as prime, letting an attacker supply a composite
modulus with a smooth factorization for small-subgroup recovery of the
private exponent and shared secret.
When no RNG is supplied on the untrusted path, create a temporary RNG so
mp_prime_is_prime_ex runs with random witnesses, which such crafted
composites cannot reliably pass. Named FFDHE primes still short-circuit
the check, and builds without an RNG keep the deterministic test.
Fixes F-6776.
wc_ecc_shared_secret_gen_sync ran the scalar multiplication and then
copied the x-coordinate to the output without checking whether the
result was the point at infinity. Both math backends report success for
the identity: ecc_map_ex sets x, y to zero and z to one and returns
success, and the single precision generators serialize the identity as
an all-zero x-coordinate. Either way a shared secret that computed to
infinity was handed back as an all-zero secret with a success code,
where SP 800-56Ar3 5.7.1.2 requires an error and stop.
Check the mapped point on the software path, and detect the all-zero
output after the single precision generators, returning ECC_INF_E in
both cases. The scan accumulates over the whole buffer so it does not
branch on the secret.
A key whose private value is resident in an SE050 carries no software
scalar, so the software multiply legitimately yields the identity for
it. Skip the check for those keys specifically, rather than for a zero
scalar: on a prime-order curve a zero scalar is the one way the identity
can arise, so exempting it would disable the check for the case it
exists to catch.
Fixes F-6770.
wc_Chacha_Process validated only its pointer arguments and then produced
keystream directly from the context state. A zero-initialized ChaCha
context, common for static or global storage, that received a nonce via
wc_Chacha_SetIV but never had wc_Chacha_SetKey called would encrypt with
an all-zero, attacker-predictable key and still return success. This is
the same fail-open class already guarded against in wc_Arc4Process.
Add a keySet flag to the ChaCha struct, set it in wc_Chacha_SetKey, and
return MISSING_KEY from wc_Chacha_Process when the key was never set.
Fixes F-6893.
psoc6_ecc_verify_hash_ex serialized the signature r and s components
into a fixed 132-byte stack buffer using mp_to_unsigned_bin without
checking their sizes. The values come from attacker-supplied ASN.1 in
DecodeECC_DSA_Sig with no magnitude cap beyond sp_int capacity, so an
oversized r or s wrote past signature_buf, a pre-authentication stack
overflow reachable during TLS signature verification. The generic path
guards this with wc_ecc_check_r_s_range, but that check is compiled out
on WOLFSSL_PSOC6_CRYPTO builds and the port function performed no r/s
validation of its own. Reject any r or s whose serialized size exceeds
the key size before writing into the buffer.
Fixes F-6778.
The assembly/SP generators had been modified but not all output files were
generated.
All files now are up to date with the latest generator scripts, that were fixed.
wolfevent.c (the wolfEvent completion queue) only compiled under
--enable-asynccrypt: AM_CONDITIONAL([BUILD_WOLFEVENT],...) tested only
ENABLED_ASYNCCRYPT. But HAVE_WOLF_EVENT is a user-settable macro that
internal.c/ssl.c gate their wolfEventQueue_* references on, so a
--enable-usersettings build that defines HAVE_WOLF_EVENT referenced the
queue API while the object was never built -> link error (undefined
wolfEventQueue_Init/Free). BUILD_WOLFEVENT was also the only BUILD_*
conditional missing the standard "|| ENABLED_USERSETTINGS = yes" escape
hatch that lets a header-driven build compile a source and defer the
decision to the file's own #ifdef.
Add that clause (matching BUILD_FALCON/BUILD_MLKEM/etc.) so usersettings
builds compile wolfevent.c; its internal #ifdef HAVE_WOLF_EVENT still
gates whether the code is active, so non-event builds get an empty object.
Also silence wolfEvent_Poll's unused-parameter -Werror in non-async builds
(event/flags are consumed only by the async hardware poll), which the
above change surfaces now that the file compiles without WOLFSSL_ASYNC_CRYPT.
Restore the original short-circuit XMALLOC chains and leave the zeroing to
mp_init_multi(). On a partial allocation failure mp_init_multi() is skipped,
so nothing is initialized: free whatever was allocated right there and NULL
the pointers, so the shared cleanup at the end of the function never calls
mp_clear()/mp_forcezero() on an allocated-but-uninitialized mp_int.
No extra mp_init() calls, no XMEMSET, and the returned error codes are
unchanged.
Initialize the mp_int temporaries as soon as they are allocated in
wc_CompareDiffPQ(), _CheckProbablePrime() and wc_CheckProbablePrime_ex(),
so the cleanup path handles them consistently in all cases.
wc_mlkem.h/test_mlkem.c: Respect WC_NO_CONSTRUCTORS guard.
settings.h, fe_operations.h: move WOLFSSL_CURVE25519_USE_ED25519 derivation into settings.h so the assembler sees it; fixes fe_cmov_table undefined on ARM32.
ge_448.c: shift the product instead of the byte in six sc448_* loops, dodging a GCC ARM32 NEON miscompile that produced wrong ed448 signatures; table shrunk [56]→[28].
Every fpr backend except the default integer-emulated one runs on the FP/vector
register file: WOLFSSL_FALCON_FPR_DOUBLE (C double -> SSE) and the generated
x86-64 fpr asm use xmm, and the folded AVX2/NEON FFT uses ymm / Q registers. All
of them must save and restore those registers around the work that uses fpr --
kernel FPU state under WOLFSSL_LINUXKM and the DEBUG_VECTOR_REGISTER_ACCESS
check. A single gate, WOLFSSL_FALCON_SAVE_VREGS (set for FPR_DOUBLE, FPR_ASM,
FFT_AVX2 or FFT_NEON), drives the wrapping so the emulated integer build stays
untouched.
The saves sit at the two int-returning orchestrators (falcon_native_make_key
around falcon_keygen; falcon_native_sign_msg around the tree build + ffSampling
loop) and read like every other fallible step: "ret = SAVE_VECTOR_REGISTERS2();
if (ret != 0) goto out;", propagating a save failure through normal cleanup.
Nested saves inside SHAKE256 are reference-counted. Verified with
DEBUG_VECTOR_REGISTER_ACCESS (+ABORT_ON_FAIL and fuzzing) on the double, asm and
avx2 backends: balanced counts, no unsaved FP/SIMD, graceful failure path.
linuxkm/lkcapi_aes_glue.c and linuxkm/lkcapi_sha_glue.c: add CMAC and SHA-3 to algs warned for incompatibility with kernels <5.6;
linuxkm/lkcapi_aes_glue.c, wolfcrypt/src/aes.c, wolfcrypt/src/memory.c, and wolfssl/wolfcrypt/memory.h: fix WC_DEBUG_CIPHER_LIFECYCLE in kernel mode (km_AesGet() and km_AesCmacMaterialize()), add WARN_UNUSED_RESULT to wc_debug_CipherLifecycle*(), and fix an unchecked wc_debug_CipherLifecycleFree() in wc_AesFree();
linuxkm/lkcapi_aes_glue.c: fix unsafe wc_CmacFree() call in km_AesCmacSetKey();
linuxkm/lkcapi_sha_glue.c: in km_hmac_export(), avoid unlocked access to snapshot->desc_id (possible UAF under extreme pressure).
* Revert earlier changes adding WC_SHA256_W_SIZE and WC_SHA512_W_SIZE.
* Add WC_SHA2_NO_SMALL_STACK to allow the W work buffer to move back onto the
stack.
* In wolfssl/wolfcrypt/settings.h, define WC_SHA2_NO_SMALL_STACK by default when
WOLFSSL_KERNEL_MODE, and add a clause to #undef WOLFSSL_SMALL_STACK when
building the SHA-2 implementations.
linuxkm/lkcapi_sha_glue.c:
* Refactor out superfluous struct km_sha_state.
* Clean up some macro dynamics.
* Add static asserts on HASH_MAX_STATESIZE to WC_LINUXKM_SHA1_IMPLEMENT() and
WC_LINUXKM_SHA2_IMPLEMENT().
* separate WC_LINUXKM_SHA_IMPLEMENT() into WC_LINUXKM_SHA1_IMPLEMENT() (no fixes
needed) and WC_LINUXKM_SHA2_IMPLEMENT() (with associated new helpers
WC_LINUXKM_SHA2_FREE_W(), WC_LINUXKM_SHA2_DECL_W(), WC_LINUXKM_SHA2_PUSH_W(),
and WC_LINUXKM_SHA2_POP_W(), that move .W to a stack buffer).
* Reimplement SHA-2 one-shot digest callback to use only direct wolfCrypt calls
rather than proxy to other callbacks.
Tobias Frauenschläger
David GarskeandGitHub
Daniel PouzznerandGitHub
Sean Parkinson
Anthony Hu
Daniele Lacamera
night1rider
JacobBarthelmehandGitHub