NULL pointer dereference after using mbedtls_asn1_store_named_data()

Title

NULL pointer dereference after using mbedtls_asn1_store_named_data()

CVE

CVE-2025-48965

Date

30 June 2025

Affects

all versions of Mbed TLS up to 3.6.3

Not affected

Mbed TLS 3.6.4 and later 3.6 versions, upcoming Mbed TLS 4.x versions

Impact

NULL pointer dereference (CWE-476)

Severity

MEDIUM

Credits

Found by Linh Le and Ngan Nguyen from Calif.

Vulnerability

In some circumstances (see below), mbedtls_asn1_store_named_data() leaves its output list with an item in an inconsistent state with val.p == NULL but val.len > 0. In that case, future uses of the list, either by the same function or by other functions, are likely to dereference val.p, a NULL pointer.

There are two ways this can happen:

  1. By calling mbedtls_asn1_store_named_data() directly.

  2. By calling it indirectly via mbedtls_x509_string_to_names() or associated functions (listed below).

When calling mbedtls_x509_string_to_names() directly, the problem happens when an item with a certain OID has already been entered into the list, then mbedtls_asn1_store_named_data() is called with the same OID and val_len = 0. It then free()s val.p as documented, but fails to update val.len. Calling mbedtls_asn1_store_named_data() again with the same OID (and a length not greater than the last non-zero length) will cause a NULL pointer dereference. Using the list in other ways is likely to also cause a NULL dereference.

The fault in mbedtls_asn1_store_named_data() can also be triggered by malicious input when used indirectly via the following string-parsing functions:

  • mbedtls_x509_string_to_names(),

  • mbedtls_x509write_crt_set_subject_name(),

  • mbedtls_x509write_crt_set_issuer_name(),

  • mbedtls_x509write_csr_set_subject_name().

With these functions, the incorrect behaviour is triggered by input strings that contain at least two entries with the same type: one with a non-zero length, and a subsequent one of length zero.

This causes the list to contain an item in an inconsistent state; the NULL dereference itself will happen either in a subsequent call to mbedtls_x509_write_names() using that list, or directly within the same call to mbedtls_x509_string_to_names() (or one of its wrappers as listed above) if there is another entry with the same type after the one of length zero.

Specifically, inputs like “DC=foo,DC=#0000” will parse apparently successfully, but using the output list (or CRT/CSR structure) with other functions will cause them to dereference a NULL pointer. Inputs like “DC=foo,DC=#0000,DC=bar” will cause a NULL dereference directly in the string parsing function.

Impact

NULL pointer dereference, leading to DoS on platforms with memory protection, and possibly code execution on microcontrollers without an MMU or MPU.

Affected versions

All versions of Mbed TLS up to Mbed TLS 3.6.3 included are affected.

The first fixed version is Mbed TLS 3.6.4.

Resolution

Affected users should upgrade to Mbed TLS 3.6.4 (or TF-PSA-Crypto 1.x / Mbed TLS 4.x once they are released).

Work-around

Applications that do not call mbedtls_asn1_store_named_data() or any of the string-parsing functions mentioned above are not affected. Applications that call these functions only with trusted inputs are not affected.

Note that these functions are used to create certificates or CSRs; as a result, applications that only use but do not create certificates or CSRs should not be affected.