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.

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.

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 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.)

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.

Mbed TLS before 3.6.4 has a NULL pointer dereference because mbedtlsasn1storenameddata can trigger conflicting data with val.p of NULL but val.len greater than zero.

Mbed TLS through 3.6.4 has an Observable Timing Discrepancy.