An integer overflow was discovered in the CoAP library in Arm Mbed OS 5.14.0. The function sncoapbuildercalcneededpacketdatasize2() is used to calculate the required memory for the CoAP message from the sncoaphdrs data structure. Both returnedbytecount and srccoapmsgptr->payloadlen are of type uint16t. When added together, the result returnedbytecount can wrap around the maximum uint16t value. As a result, insufficient buffer space is allocated for the corresponding CoAP message.

Buffer overflows were discovered in the CoAP library in Arm Mbed OS 5.14.0. The CoAP parser is responsible for parsing received CoAP packets. The function sncoapparseroptionsparse() parses CoAP input linearly using a while loop. Once an option is parsed in a loop, the current point (packetdatapptr) is increased correspondingly. The pointer is restricted by the size of the received buffer, as well as by the 0xFF delimiter byte. Inside each while loop, the check of the value of packetdatapptr is not strictly enforced. More specifically, inside a loop, packetdatapptr could be increased and then dereferenced without checking. Moreover, there are many other functions in the format of sncoapparser() that do not check whether the pointer is within the bounds of the allocated buffer. All of these lead to heap-based or stack-based buffer overflows, depending on how the CoAP packet buffer is allocated.

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.

In Mbed TLS before 3.1.0, psaaeadgeneratenonce allows policy bypass or oracle-based decryption when the output buffer is at memory locations accessible to an untrusted application.

An issue was discovered in Arm Mbed TLS before 2.24.0. mbedtlsx509crlparseder has a buffer over-read (of one byte).

ARM mbedTLS version 2.7.0 and earlier contains a Ciphersuite Allows Incorrectly Signed Certificates vulnerability in mbedtlssslgetverifyresult() that can result in ECDSA-signed certificates are accepted, when only RSA-signed ones should be.. This attack appear to be exploitable via Peers negotiate a TLS-ECDH-RSA- ciphersuite. Any of the peers can then provide an ECDSA-signed certificate, when only an RSA-signed one should be accepted..

An issue was discovered in Mbed TLS before 2.25.0 (and before 2.16.9 LTS and before 2.7.18 LTS). The calculations performed by mbedtlsmpiexpmod are not limited; thus, supplying overly large parameters could lead to denial of service when generating Diffie-Hellman key pairs.

An issue was discovered in Mbed TLS before 2.25.0 (and before 2.16.9 LTS and before 2.7.18 LTS). A NULL algorithm parameters entry looks identical to an array of REAL (size zero) and thus the certificate is considered valid. However, if the parameters do not match in any way, then the certificate should be considered invalid.

An issue was discovered in Mbed TLS before 2.24.0 (and before 2.16.8 LTS and before 2.7.17 LTS). There is missing zeroization of plaintext buffers in mbedtlssslread to erase unused application data from memory.

An issue was discovered in Arm Mbed TLS before 2.23.0. A remote attacker can recover plaintext because a certain Lucky 13 countermeasure doesn't properly consider the case of a hardware accelerator.

A Denial of Service vulnerability exists in mbed TLS 3.0.0 and earlier in the mbedtlspkcs12derivation function when an input password's length is 0.

An issue was discovered in Mbed TLS before 2.24.0. The verification of X.509 certificates when matching the expected common name (the cn argument of mbedtlsx509crtverify) with the actual certificate name is mishandled: when the subjecAltName extension is present, the expected name is compared to any name in that extension regardless of its type. This means that an attacker could impersonate a 4-byte or 16-byte domain by getting a certificate for the corresponding IPv4 or IPv6 address (this would require the attacker to control that IP address, though).

Arm Mbed TLS before 2.16.5 allows attackers to obtain sensitive information (an RSA private key) by measuring cache usage during an import.

A Lucky 13 timing side channel in mbedtlsssldecryptbuf in library/sslmsg.c in Trusted Firmware Mbed TLS through 2.23.0 allows an attacker to recover secret key information. This affects CBC mode because of a computed time difference based on a padding length.

An issue was discovered in Arm Mbed TLS before 2.23.0. Because of a side channel in modular exponentiation, an RSA private key used in a secure enclave could be disclosed.

An issue was discovered in Arm Mbed TLS before 2.24.0. It incorrectly uses a revocationDate check when deciding whether to honor certificate revocation via a CRL. In some situations, an attacker can exploit this by changing the local clock.

An issue was discovered in Arm Mbed TLS before 2.23.0. A side channel allows recovery of an ECC private key, related to mbedtlsecpcheckpubpriv, mbedtlspkparsekey, mbedtlspkparsekeyfile, mbedtlsecpmul, and mbedtlsecpmulrestartable.

In Trusted Firmware Mbed TLS 2.24.0, a side-channel vulnerability in base64 PEM file decoding allows system-level (administrator) attackers to obtain information about secret RSA keys via a controlled-channel and side-channel attack on software running in isolated environments that can be single stepped, especially Intel SGX.

An issue was discovered in Arm Mbed TLS before 2.24.0. An attacker can recover a private key (for RSA or static Diffie-Hellman) via a side-channel attack against generation of base blinding/unblinding values.

The ECDSA signature implementation in ecdsa.c in Arm Mbed Crypto 2.1 and Mbed TLS through 2.19.1 does not reduce the blinded scalar before computing the inverse, which allows a local attacker to recover the private key via side-channel attacks.