Memory Safety Vulnerabilities in Renesas FSP Cryptographic and Networking Code
SecMate found seven vulnerabilities in Renesas FSP [1], the Flexible Software Package for Renesas RA microcontrollers [2]. FSP is the vendor software stack for RA devices and bundles BSP code, HAL drivers, middleware, and security integrations, including hardware-backed cryptography and Mbed TLS support.
In the v6.1.0 FSP codebase we analyzed at commit ed247f90fb9bc390ebd36f1a0b7847b0ff44f322 [3], we found issues in RSA verification, the hardware-accelerated AES-XTS path, GCM decrypt handling, and the RMAC receive path. These are implementation flaws in FSP integration code around hardware-backed cryptography and networking. They are not flaws in AES, GCM, CCM, XTS, or RSA as algorithms.
Advisory Map
| Area | Vulnerability | SecMate Advisory | Renesas Advisory |
|---|---|---|---|
| RMAC | Read buffer overflow in r_rmac.c | SECMATE-2025-0021 | renesas/fsp#431 |
| RSA | Signature verification pointer underflow in r_sce_rsa.c | SECMATE-2025-0019 | renesas/fsp#423 |
| AES-XTS | Encrypt and decrypt finalization overflows in aes_alt_process.c | SECMATE-2025-0020 | renesas/fsp#427 |
| GCM | Tag length buffer overflow in gcm_alt_process.c | SECMATE-2025-0022 | renesas/fsp#428 |
| CCM | Tag length buffer overflow in ccm_alt_process.c | SECMATE-2025-0023 | renesas/fsp#430 |
| CCM adaptor | MAC length buffer overflow in r_sce_AES_adapt.c | SECMATE-2025-0024 | renesas/fsp#429 |
The AES-XTS advisory covers two findings, one in the encrypt finalization path and one in the decrypt finalization path.
Affected Builds and Use Cases
SecMate’s published disclosure advisories are available on the SecMate disclosures page [4]. The table above links both the SecMate advisory and the corresponding Renesas public advisory for each vulnerability group.
These cryptography-related findings do not apply to every RA build. In FSP, the accelerated AES and AEAD paths are compiled for devices with SCE5, SCE5B, SCE7, SCE9, or RSIP support, and the XTS path is excluded on RA2 parts.
In downstream products, these APIs may be used for signature verification, authenticated decryption, encrypted storage, firmware update, or other security-sensitive processing. Exposure therefore depends on whether untrusted inputs can reach those wrappers.
The RMAC finding is separate from the cryptographic code paths. It affects products using the Ethernet receive API if application code provides a buffer smaller than the received frame.
Renesas PSIRT acknowledged the reports and published public advisories on GitHub.
Recommendations
- If you use affected RA builds, review the Renesas advisories and update to
FSP v6.3.0or later. - In downstream products, check whether untrusted inputs can reach FSP wrappers used for signature verification, authenticated decryption, encrypted storage, or firmware update handling.
- Add negative tests for malformed signatures, AEAD metadata, XTS lengths, and oversized Ethernet frames.
- If you use
r_rmac, verify that receive buffers are sized for the largest frame your product accepts.
Timeline
ed247f90fb9bc390ebd36f1a0b7847b0ff44f322 (v6.1.0).FSP v6.3.0, which contains the public fixes [5].Takeaway
The common thread is not broken cryptography. It is memory safety in the FSP code that exposes cryptographic and Ethernet functionality to RA applications. Hardware-backed cryptography still depends on the surrounding integration code.
For the full list of our disclosures, see our disclosure page [4]. If you are building embedded systems and want to find vulnerabilities before attackers do, reach out.
References
[1] Renesas. “Renesas Flexible Software Package.” GitHub. Repository
[2] Renesas. “Renesas Flexible Software Package Documentation.” Documentation
[3] Renesas. “FSP v6.1.0 analyzed commit” (
ed247f90fb9bc390ebd36f1a0b7847b0ff44f322). Commit[4] SecMate. “Disclosures.” Disclosure page
[5] Renesas. “FSP v6.3.0.” GitHub Releases. Release
The SecMate Team
Written by.
