package/mbedtls: security bump to v3.6.4
This is a security release of the Long Term Support branch, see release notes:
https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-3.6.4
Also update the download location, because upstream changed the tag naming
scheme from v<...> to mbedtls-<...>
This fixes the following vulnerabilities:
- CVE-2025-47917
Fix possible use-after-free or double-free in code calling
mbedtls_x509_string_to_names(). This was caused by the function calling
mbedtls_asn1_free_named_data_list() on its head argument, while the
documentation did no suggest it did, making it likely for callers relying
on the documented behaviour to still hold pointers to memory blocks after
they were free()d, resulting in high risk of use-after-free or double-free,
with consequences ranging up to arbitrary code execution.
In particular, the two sample programs x509/cert_write and x509/cert_req
were affected (use-after-free if the san string contains more than one DN).
Code that does not call mbedtls_string_to_names() directly is not affected.
- CVE-2025-48965
Fix a bug in mbedtls_asn1_store_named_data() where it would sometimes leave
an item in the output list in an inconsistent state with val.p == NULL but
val.len > 0. This impacts applications that call this function directly,
or indirectly via mbedtls_x509_string_to_names() or one of the
mbedtls_x509write_{crt,csr}set{subject,issuer}_name() functions. The
inconsistent state of the output could then cause a NULL dereference either
inside the same call to mbedtls_x509_string_to_names(), or in subsequent
users of the output structure, such as mbedtls_x509_write_names(). This
only affects applications that create (as opposed to consume) X.509
certificates, CSRs or CRLs, or that call mbedtls_asn1_store_named_data()
- CVE-2025-49087
Fix a timing side channel in the implementation of PKCS#7 padding
which would allow an attacker who can request decryption of arbitrary
ciphertexts to recover the plaintext through a timing oracle attack.
- CVE-2025-49600:
In MbedTLS 3.3.0 before 3.6.4, mbedtls_lms_verify 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 mbedtls_lms_verify 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 mbedtls_lms_verify, the return
values of the internal Merkle tree functions create_merkle_leaf_value
and create_merkle_internal_value are not checked. These functions
return an integer that indicates whether the call succeeded or not. If
a failure occurs, the output buffer (Tc_candidate_root_node) 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.
https://www.cve.org/CVERecord?id=CVE-2025-49600
- CVE-2025-49601:
In MbedTLS 3.3.0 before 3.6.4, mbedtls_lms_import_public_key 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
mbedtls_lms_import_public_key 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 mbedtls_lms_import_public_key reads this type indicator
before validating the size of its input.
https://www.cve.org/CVERecord?id=CVE-2025-49601
- CVE-2025-52496:
Mbed TLS before 3.6.4 has a race condition in AESNI detection if
certain compiler optimizations occur. An attacker may be able to
extract an AES key from a multithreaded program, or perform a GCM
forgery.
https://www.cve.org/CVERecord?id=CVE-2025-52496
- CVE-2025-52497:
Mbed TLS before 3.6.4 has a PEM parsing one-byte heap-based buffer
underflow, in mbedtls_pem_read_buffer and two mbedtls_pk_parse
functions, via untrusted PEM input.
https://www.cve.org/CVERecord?id=CVE-2025-52497
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
[Julien: fix upstream hash URL in hash file]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Titouan Christophe