Memory leak in mbed pk

Hello forum,

I encounters some memory leak issues with the implementation of ecdsa digital signature with the mbedtls pk.

Mbedtls is implemented on ARM processor and use static memory (Using the mbed TLS Buffer Allocator). The version is mbedtls-2.16.1-apache.

The firmware implements other crypto functions without memory problem.

The problem is in this part of code:
mbedtls_pk_init (…)
mbedtls_pk_parse_public_key (…) //EC key in DER Curve secp224r1
mbedtls_pk_verify (…)
mbedtls_pk_free (…)

While the code operates well, around 1,7 KB of memory are not freeing at the end of the sequence.
Current investigation shows that the memory leak in ecdsa_verify_restartable around
MBEDTLS_MPI_CHK( mbedtls_ecp_muladd_restartable( grp,&R, pu1, &grp->G, pu2, Q, ECDSA_RS_ECP ) );

Any idea what to do?

Thanks for your help
Alexandre

Hi Alexandre,

I don’t recall any known bug here. We do have tests with a similar init-parse-verify-free sequence that pass under a leak detector, but it’s possible that we never tested your exact configuration. Can you please share your exact configuration and a small program that would allow us to reproduce the problem?


Gilles Peskine (Mbed TLS team member)

Dear Gilles,

Thanks for your reply and your help. Here after the piece of code and the config.h as well as debug traces.
MbedTLS runs on ARM946 on RTOS (proprietary). The pk_verify code is including in a single task.
We suppress all other call to mbedtls (to be sure that we have not a problem related to multitask).

In the debug traces you can see that the memory consumption increase (until the pk_verify fails) .

The code, config.h and debug traces are available here:
http://www.fdc.fr/dl/mbtls_memory_leak.zip
Alexandre


init performed before calling the verify code:

mbedtls_memory_buffer_alloc_init( tls_memory_buf, sizeof(tls_memory_buf) );
mbedtls_entropy_init(&entropy);
mbedtls_ctr_drbg_init(&ctr_drbg);
mbedtls_ctr_drbg_seed( &ctr_drbg, mbedtls_entropy_func, &entropy,
(const unsigned char *) pers,
sizeof pers );

Gilles,

I found the problem. It was a problem of missaligment memory buffer.
Setting MBEDTLS_MEMORY_ALIGN_MULTIPLE to 4 solved the problem

Alexandre