The SANCTUARY team uncovered a stack‑based buffer overflow in wolfTPM’s wolfTPM2_RsaKey_TpmToWolf function, occurring when RSA keys larger than the default 2048‑bit configuration are exported without adequate bounds checking, as documented in CVE‑2025‑7844. This vulnerability arises particularly when oversized keys are imported via public‑key pathways and not constrained by compile-time configuration, enabling potential stack corruption. Mitigation involves upgrading to the patched version (3.9.2 or later) or adjusting compile‑time RSA bit limits to match expected key sizes.
wolfTPM is a portable, C-based TPM 2.0 stack and wrapper layer produced by wolfSSL that targets embedded use. It implements the TPM 2.0 command set, provides a hardware abstraction for common buses and exposes a high-level wrapper API that simplifies tasks such as key generation, storage, attestation, sealing and TLS integrations. The library can talk to hardware TPMs via the Linux kernel interface or directly over SPI and I²C, and ships with extensive examples and documentation for typical workflows.
This post documents a stack-based buffer overflow in the RSA export wrapper wolfTPM2_RsaKey_TpmToWolf. The issue is tracked publicly as CVE-2025-7844 and is fixed in wolfTPM v3.9.2. The vulnerability allows an attacker to overrun a fixed-size stack buffer when converting a TPM-resident RSA public key to a wolfCrypt RsaKey, if larger-than-expected key material reaches the wrapper at runtime.
Where the Bug Sits
The wrapper layer declares the conversion function as:
WOLFTPM_API int wolfTPM2_RsaKey_TpmToWolf( OLFTPM2_DEV* dev, WOLFTPM2_KEY* tpmKey, RsaKey* wolfKey);
The function’s purpose is to read the RSA public modulus and exponent from a TPM 2.0 public area and feed them into a wolfCrypt RsaKey. This API is part of the documented “wolfTPM2 Wrappers” interface, alongside helpers to import and export keys, including wolfTPM2_ImportPublicKeyBuffer.
wolfTPM’s TPM structure definitions follow the TPM 2.0 conventions. The RSA public component is represented as TPM2B_PUBLIC_KEY_RSA, which contains a two-byte length and a modulus buffer sized by the MAX_RSA_KEY_BYTES macro.
The bug stems from a mismatch between two build-time size assumptions and one runtime size. wolfTPM uses a compile-time constant for the wrapper’s temporary buffer size. By default the wrapper derives WOLFTPM2_WRAP_RSA_KEY_BITS from MAX_RSA_KEY_BITS which defaults to 2048, so a local stack buffer n is allocated to hold 2048/8 bits, i.e. 256 bytes:
byte n[WOLFTPM2_WRAP_RSA_KEY_BITS / 8]; /* 256 bytes if 2048-bit default */
/* load public key */
nSz = tpmKey->pub.publicArea.unique.rsa.size;
XMEMCPY(n, tpmKey->pub.publicArea.unique.rsa.buffer, nSz);
If a 3072-bit or 4096-bit RSA key reaches this path in a build compiled with the default 2048-bit wrapper buffer, the XMEMCPY overflows the 256-byte stack buffer, triggering a classic CWE-121 condition. The RSA public structure itself is large enough to hold bigger keys because MAX_RSA_KEY_BYTES accounts for larger bit sizes, so the source buffer can legitimately exceed the destination.
wolfSSL’s has acknowledged the problem and assigned CVE-2025-7844. wolfTPM 3.9.2 fixes this buffer overflow, but also adds bounds checks throughout the project.
Why Exploitation is Plausible
The wrapper API includes helpers that import public keys from external buffers and files. In particular, wolfTPM2_ImportPublicKeyBuffer can ingest a DER or PEM RSA public key without involving the TPM’s key-creation limits, which means an application can create in-memory TPM2B_PUBLIC data with a modulus larger than the default wrapper expectation. Keys loaded as TPM keyblobs via the hardware would typically be constrained by the TPM’s capabilities, but externally imported public keys do not benefit from that hardware guardrail. If such a key subsequently flows into wolfTPM2_RsaKey_TpmToWolf, the unchecked copy can overrun the fixed-size stack buffer. Note, that depending on the concrete scenario, the malicious public key can be created by another process and loaded by the victim process, even without physical presence. Depending on compilation flags and surrounding frame layout, consequences range from program aborts with stack canaries or sanitizers to potential control-flow hijack in non-hardened builds.
Patch and Configuration Guidance
wolfSSL fixed the issue in v3.9.2 by hardening buffer size checks in the RSA export path and related areas. Users should upgrade to wolfTPM v3.9.2 or later. The release notes specify that a stack overrun is also avoided when the build-time macro MAX_RSA_KEY_BITS is set correctly to match the maximum RSA size supported by the target TPM and application. While correct configuration mitigates the risk, relying solely on configuration is fragile because higher-level import paths can still introduce larger public keys into memory if the code path does not constrain them.
We want to thank the wolfSSL team for the easy and fast process, and congratulate Richard Mitev, Giannis Mouzenidis, and Patrick Jauernig to the findings. This vulnerability has been found during our on-going ESA activity on using a TPM as a service on a satellite.
