In Mbed TLS 3.3.0 through 3.5.2 before 3.6.0, a malicious client can cause information disclosure or a denial of service because of a stack buffer over-read (of less than 256 bytes) in a TLS 1.3 server via a TLS 3.1 ClientHello.

In MbedTLS 3.3.0 before 3.6.4, mbedtlslmsimportpublickey does not check that the input buffer is at least 4 bytes before reading a 32-bit field, allowing a possible out-of-bounds read on truncated input. Specifically, an out-of-bounds read in mbedtlslmsimportpublickey allows context-dependent attackers to trigger a crash or limited adjacent-memory disclosure by supplying a truncated LMS (Leighton-Micali Signature) public-key buffer under four bytes. An LMS public key starts with a 4-byte type indicator. The function mbedtlslmsimportpublickey reads this type indicator before validating the size of its input.

Mbed TLS v3.3.0 up to 3.6.5 and 4.0.0 allows Algorithm Downgrade.

In MbedTLS 3.3.0 before 3.6.4, mbedtlslmsverify may accept invalid signatures if hash computation fails and internal errors go unchecked, enabling LMS (Leighton-Micali Signature) forgery in a fault scenario. Specifically, unchecked return values in mbedtlslmsverify allow an attacker (who can induce a hardware hash accelerator fault) to bypass LMS signature verification by reusing stale stack data, resulting in acceptance of an invalid signature. In mbedtlslmsverify, the return values of the internal Merkle tree functions createmerkleleafvalue and createmerkleinternalvalue are not checked. These functions return an integer that indicates whether the call succeeded or not. If a failure occurs, the output buffer (Tccandidaterootnode) may remain uninitialized, and the result of the signature verification is unpredictable. When the software implementation of SHA-256 is used, these functions will not fail. However, with hardware-accelerated hashing, an attacker could use fault injection against the accelerator to bypass verification.