An issue was discovered in Mbed TLS 3.x before 3.6.6. An out-of-bounds read vulnerability in mbedtlsccmfinish() in library/ccm.c allows attackers to obtain adjacent CCM context data via invocation of the multipart CCM API with an oversized taglen parameter. This is caused by missing validation of the taglen parameter against the size of the internal 16-byte authentication buffer. The issue affects the public multipart CCM API in Mbed TLS 3.x, where mbedtlsccmfinish() can be invoked directly by applications. In Mbed TLS 4.x versions prior to the fix, the same missing validation exists in the internal implementation; however, the function is not exposed as part of the public API. Exploitation requires application-level invocation of the multipart CCM API.

An issue was discovered in Mbed TLS versions from 2.19.0 up to 3.6.5, Mbed TLS 4.0.0. Insufficient protection of serialized SSL context or session structures allows an attacker who can modify the serialized structures to induce memory corruption, leading to arbitrary code execution. This is caused by Incorrect Use of Privileged APIs.

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

Mbed TLS before 3.6.6 and TF-PSA-Crypto before 1.1.0 misuse seeds in a Pseudo-Random Number Generator (PRNG).

Mbed TLS 3.5.0 to 3.6.5 fixed in 3.6.6 and 4.1.0 has a buffer overflow in the x509inetptonipv6() function

An issue was discovered in Mbed TLS through 3.6.5 and TF-PSA-Crypto 1.0.0. A buffer overflow can occur in public key export for FFDH keys.

An issue was discovered in Mbed TLS through 3.6.5 and 4.x through 4.0.0. There is a NULL pointer dereference in distinguished name parsing that allows an attacker to write to address 0.

An issue was discovered in Mbed TLS 3.5.0 through 4.0.0. Client impersonation can occur while resuming a TLS 1.3 session.

In Mbed TLS 3.6.1 through 3.6.3 before 3.6.4, a timing discrepancy in block cipher padding removal allows an attacker to recover the plaintext when PKCS#7 padding mode is used.

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.

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 before 2.28.10 and 3.x before 3.6.3, on the client side, accepts servers that have trusted certificates for arbitrary hostnames unless the TLS client application calls mbedtlssslsethostname.

Mbed TLS before 2.28.10 and 3.x before 3.6.3, in some cases of failed memory allocation or hardware errors, uses uninitialized stack memory to compose the TLS Finished message, potentially leading to authentication bypasses such as replays.

Mbed TLS 3.5.x through 3.6.x before 3.6.2 has a buffer underrun in pkwrite when writing an opaque key pair

An issue was discovered in Mbed TLS 3.6 before 3.6.1. A stack buffer overflow in mbedtlsecdsadertoraw() and mbedtlsecdsarawtoder() can occur when the bits parameter is larger than the largest supported curve. In some configurations with PSA disabled, all values of bits are affected. (This never happens in internal library calls, but can affect applications that call these functions directly.)

An issue was discovered in Mbed TLS 3.x before 3.6.1. With TLS 1.3, when a server enables optional authentication of the client, if the client-provided certificate does not have appropriate values in if keyUsage or extKeyUsage extensions, then the return value of mbedtlssslgetverifyresult() would incorrectly have the MBEDTLSX509BADCERTKEYUSAGE and MBEDTLSX509BADCERTKEYUSAGE bits clear. As a result, an attacker that had a certificate valid for uses other than TLS client authentication would nonetheless be able to use it for TLS client authentication. Only TLS 1.3 servers were affected, and only with optional authentication (with required authentication, the handshake would be aborted with a fatal alert).

An issue was discovered in Mbed TLS before 2.28.9 and 3.x before 3.6.1, in which the user-selected algorithm is not used. Unlike previously documented, enabling MBEDTLSPSAHMACDRBGMDTYPE does not cause the PSA subsystem to use HMACDRBG: it uses HMACDRBG only when MBEDTLSPSACRYPTOEXTERNALRNG and MBEDTLSCTRDRBGC are disabled.

An issue was discovered in Mbed TLS 3.5.x before 3.6.0. When an SSL context was reset with the mbedtlssslsessionreset() API, the maximum TLS version to be negotiated was not restored to the configured one. An attacker was able to prevent an Mbed TLS server from establishing any TLS 1.3 connection, potentially resulting in a Denial of Service or forced version downgrade from TLS 1.3 to TLS 1.2.

An issue was discovered in Mbed TLS 3.5.x before 3.6.0. When negotiating the TLS version on the server side, it can fall back to the TLS 1.2 implementation of the protocol if it is disabled. If the TLS 1.2 implementation was disabled at build time, a TLS 1.2 client could put a TLS 1.3-only server into an infinite loop processing a TLS 1.2 ClientHello, resulting in a denial of service. If the TLS 1.2 implementation was disabled at runtime, a TLS 1.2 client can successfully establish a TLS 1.2 connection with the server.

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.

An issue was discovered in Mbed TLS 2.18.0 through 2.28.x before 2.28.8 and 3.x before 3.6.0 and Mbed Crypto. The PSA Crypto API mishandles shared memory.

An issue was discovered in Mbed TLS 2.x before 2.28.7 and 3.x before 3.5.2. There was a timing side channel in RSA private operations.

Integer Overflow vulnerability in Mbed TLS 2.x before 2.28.7 and 3.x before 3.5.2 allows attackers to cause a denial of service (DoS) via mbedtlsx509setextension().

An issue was discovered in Mbed TLS 3.5.1. There is persistent handshake denial if a client sends a TLS 1.3 ClientHello without extensions.

Mbed TLS 3.2.x through 3.4.x before 3.5 has a Buffer Overflow that can lead to remote Code execution.

Mbed TLS 2.x before 2.28.5 and 3.x before 3.5.0 has a Buffer Overflow.

Use of a Broken or Risky Cryptographic Algorithm in the function mbedtlsmpiexpmod() in lignum.c in Mbed TLS Mbed TLS all versions before 3.0.0 2.27.0 or 2.16.11 allows attackers with access to precise enough timing and memory access information (typically an untrusted operating system attacking a secure enclave such as SGX or the TrustZone secure world) to recover the private keys used in RSA.

An issue was discovered in Mbed TLS before 2.28.2 and 3.x before 3.3.0. There is a potential heap-based buffer overflow and heap-based buffer over-read in DTLS if MBEDTLSSSLDTLSCONNECTIONID is enabled and MBEDTLSSSLCIDINLENMAX > 2 MBEDTLSSSLCIDOUTLENMAX.

An issue was discovered in Mbed TLS before 2.28.2 and 3.x before 3.3.0. An adversary with access to precise enough information about memory accesses (typically an untrusted operating system attacking a secure enclave) can recover an RSA private key after observing the victim performing a single private-key operation if the window size (MBEDTLSMPIWINDOWSIZE) used for the exponentiation is 3 or smaller.

An issue was discovered in Mbed TLS before 2.28.1 and 3.x before 3.2.0. In some configurations, an unauthenticated attacker can send an invalid ClientHello message to a DTLS server that causes a heap-based buffer over-read of up to 255 bytes. This can cause a server crash or possibly information disclosure based on error responses. Affected configurations have MBEDTLSSSLDTLSCLIENTPORTREUSE enabled and MBEDTLSSSLINCONTENTLEN less than a threshold that depends on the configuration: 258 bytes if using mbedtlssslcookiecheck, and possibly up to 571 bytes with a custom cookie check function.