mirror of
https://github.com/wolfSSL/wolfssl.git
synced 2026-07-10 02:50:50 +02:00
7b72cf6acf
Align the RISC-V AES port's argument validation with the generic aes.c implementations (and with the port's own vector/scalar-crypto siblings): * wc_AesSetKey (base assembly variant, i.e. neither WOLFSSL_RISCV_VECTOR_CRYPTO_ASM nor WOLFSSL_RISCV_SCALAR_CRYPTO_ASM): reject key == NULL. The vector and scalar-crypto variants of the same function already check it; the base variant passed NULL through to the key expansion and wc_AesGcmSetKey then dereferenced the uninitialized schedule, crashing on e.g. wc_AesGcmSetKey(aes, NULL, 16). * wc_AesCcmEncrypt / wc_AesCcmDecrypt: reject authIn == NULL when authInSz > 0, as the generic implementation does. The port otherwise walks the NULL authIn buffer while computing the CBC-MAC. Found by the ISO 26262 per-module MC/DC campaign's argument-matrix tests (test_wc_AesGcmSetKey, test_wc_AesCcmArgMcdc) running the RISC-V port under qemu-riscv64: upstream CI only exercises this port with the KAT suite, which never passes invalid arguments.