[mbed-tls] Re: mbedTLS 3.6.6 TLS 1.3: Heap corruption issue

-- Best regards, Gilles Peskine TF-PSA-Crypto and Mbed TLS developer On 01/07/2026 17:40, Sielatchom, Cesaire via mbed-tls wrote: > > 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 528 tel:+49%202051%20201%20528 > _Cesaire.Sielatchom@bks.de mailto:Cesaire.Sielatchom@bks.de____ > __www.bks.de https://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. > >