Hello,

while setting up a TLS 1.3 client based on mbedTLS 3.6.6, I am facing a memory corruption issue and would appreciate any advice on how to debug it further.

Initial symptoms ================

Originally I was using FreeRTOS heap_4 as the allocator.

During the TLS handshake I eventually hit one of the following assertions inside the FreeRTOS heap implementation:

configASSERT( heapBLOCK_IS_ALLOCATED( pxLink ) != 0 );

configASSERT( pxLink->pxNextFreeBlock == heapPROTECT_BLOCK_POINTER( NULL ) );

This suggested corruption of the heap block header structures.

Isolation attempt =================

To exclude interactions with the FreeRTOS heap allocator, I reconfigured mbedTLS to use a dedicated static memory pool by enabling:

MBEDTLS_MEMORY_BUFFER_ALLOC_C

I allocated a dedicated 1 MB memory pool located in external RAM and initialized it via:

mbedtls_memory_buffer_alloc_init(...);

No other software component is intended to access this memory area.

New failure ===========

With the dedicated memory pool in place, the TLS 1.3 handshake now fails inside memory_buffer_alloc.c with the following consistency check:

if (cur->alloc != 0) { #if defined(MBEDTLS_MEMORY_DEBUG) mbedtls_fprintf(stderr, "FATAL: block in free_list but allocated data\n"); #endif mbedtls_exit(1); }

The execution stops with:

FATAL: block in free_list but allocated data

This appears to indicate that a block found in the free list still has its allocation flag set.

What I have checked so far ==========================

- Initially I suspected FreeRTOS heap corruption. - I added hardware watchpoints at the beginning and end of the affected memory blocks. - No obvious buffer overflow was detected using those watchpoints. - Secure and Non-Secure heaps are separated. - I experimented with MPU guard regions. - The issue is reproducible under TLS/WebSocket traffic. - mbedTLS is now running from a dedicated static memory pool. - The dedicated mbedTLS pool is approximately 1 MB and is not shared with the FreeRTOS heap.

Platform ========

- STM32U585 - TrustZone enabled - FreeRTOS - mbedTLS 3.6.6 - TLS 1.3 enabled - WebSocket over TLS

Are there recommended debugging options or allocator diagnostics that could help identify the offending allocation or the block whose metadata became inconsistent?

Has anyone experienced similar issues specifically with TLS 1.3 handshakes, especially during key share generation?

Relevant handshake log ======================

init connect[1] . Performing the SSL/TLS handshake...[TLS][2] ../SRV_TLS/mbedtls/library/ssl_tls.c:4670: => handshake [TLS][2] ../SRV_TLS/mbedtls/library/ssl_msg.c:2356: => flush output [TLS][2] ../SRV_TLS/mbedtls/library/ssl_msg.c:2365: <= flush output [TLS][2] ../SRV_TLS/mbedtls/library/ssl_tls.c:4589: client state: MBEDTLS_SSL_HELLO_REQUEST [TLS][3] ../SRV_TLS/mbedtls/library/ssl_misc.h:1353: handshake state: 0 (MBEDTLS_SSL_HELLO_REQUEST) -> 1 (MBEDTLS_SSL_CLIENT_HELLO) [TLS][2] ../SRV_TLS/mbedtls/library/ssl_msg.c:2356: => flush output [TLS][2] ../SRV_TLS/mbedtls/library/ssl_msg.c:2365: <= flush output [TLS][2] ../SRV_TLS/mbedtls/library/ssl_tls.c:4589: client state: MBEDTLS_SSL_CLIENT_HELLO [TLS][2] ../SRV_TLS/mbedtls/library/ssl_client.c:921: => write client hello [TLS][3] ../SRV_TLS/mbedtls/library/ssl_client.c:487: dumping 'client hello, random bytes' (32 bytes) [TLS][3] ../SRV_TLS/mbedtls/library/ssl_client.c:487: 0000: 9a 99 37 69 fa 5e 07 f7 ff c8 5b ac 56 fe 45 1a ..7i.^....[.V.E. [TLS][3] ../SRV_TLS/mbedtls/library/ssl_client.c:487: 0010: 53 d1 a1 d6 27 f6 5d 5a 4e 5b 2a 80 4c 1e 9b cb S...'.]ZN[*.L... [TLS][3] ../SRV_TLS/mbedtls/library/ssl_client.c:512: dumping 'session id' (0 bytes) [TLS][3] ../SRV_TLS/mbedtls/library/ssl_client.c:370: client hello, add ciphersuite: 1301, TLS1-3-AES-128-GCM-SHA256 [TLS][3] ../SRV_TLS/mbedtls/library/ssl_client.c:388: adding EMPTY_RENEGOTIATION_INFO_SCSV [TLS][3] ../SRV_TLS/mbedtls/library/ssl_client.c:397: client hello, got zu cipher suites [TLS][3] ../SRV_TLS/mbedtls/library/ssl_tls13_client.c:57: client hello, adding supported versions extension [TLS][3] ../SRV_TLS/mbedtls/library/ssl_tls13_client.c:80: supported version: [3:4] [TLS][3] ../SRV_TLS/mbedtls/library/ssl_tls13_client.c:86: supported version: [3:3] [TLS][3] ../SRV_TLS/mbedtls/library/ssl_tls13_client.c:573: no cookie to send; skip extension [TLS][3] ../SRV_TLS/mbedtls/library/ssl_tls13_client.c:285: client hello: adding key share extension [TLS][1] ../SRV_TLS/mbedtls/library/ssl_tls13_generic.c:1552: Perform PSA-based ECDH/FFDH computation. FATAL: block in free_list but allocated data

Any suggestions, debugging techniques, or similar experiences would be greatly appreciated.

Thank you very much.

Best regards, Cesaire

Mit freundlichen Grüßen / Best regards

i. A. Cesaire Sielatchom Konstrukteur und Entwickler [BKS_4c.gif] BKS GmbH Entwicklung Elektronik Heidestr. 71 D-42549 Velbert Telefon +49 2051 201 528tel:+49%202051%20201%20528 Cesaire.Sielatchom@bks.demailto:Cesaire.Sielatchom@bks.de www.bks.dehttps://www.bks.de/de-de BKS GmbH Sitz der Gesellschaft: Velbert Amtsgericht Wuppertal, HRB 17711 GF: Thomas Polonyi Vorsitzender des Aufsichtsrats: Dirk Leuker WEEE-Reg.-Nr. DE 14737171 [Email_Footer SicherheitsExpo 2026.jpg] Diese Mail ist vertraulich. Wenn Sie nicht der beabsichtigte Empfänger sind, dürfen Sie die Informationen nicht offenlegen, benutzen, kopieren oder verteilen. Wenn Sie diese Mail durch einen Fehler bekommen haben, teilen Sie uns dies bitte dadurch mit, dass Sie diese Mail an den Absender zurückschicken. Bitte löschen Sie danach diese Mail und alle Anhänge. Danke. This e-mail message including any attachment is intended for the sole use of the individual or entity named above. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others; also please notify the sender by replying to this message and then delete it and all attachments from your system.Thank you.