7 Dec
2022
7 Dec
'22
11:13 a.m.
Hi Peter,
Crashes in free() are a very common symptom of heap corruption, due to a previous buffer overflow or use-after-free or double free(). Often the bug corrupting the heap happened earlier, and the crash is just where the corruption starts to become noticeable. This makes debugging difficult.
If you can, compile your code with instrumentation such as ASan. This makes it far more likely that the corruption will be detected as soon as it happens, so debugging is easier.
You need to look at the code of your whole application. It's quite possible that the problem is not due to Mbed TLS itself, but to some other part that's corrupting the heap.
Best regards,
--
Gilles Peskine
Mbed TLS developer
On 06/12/2022 17:25, Peter via mbed-tls wrote:
>
> Hi All,
>
> Some websites crash MbedTLS, in
>
> void mbedtls_ecp_point_free( mbedtls_ecp_point *pt )
> {
> if( pt == NULL )
> return;
>
> mbedtls_mpi_free( &( pt->X ) );
> mbedtls_mpi_free( &( pt->Y ) );
> mbedtls_mpi_free( &( pt->Z ) );
> }
>
> It crashes in the last function call of the three above.
>
> Thread #1 [main] 1 [core: 0] (Suspended : Signal :
> SIGTRAP:Trace/breakpoint trap)
> HardFault_Handler() at stm32f4xx_it.c:103 0x8053c22
> <signal handler called>() at 0xffffffed
> 0x3810180
> mbedtls_ecp_point_free() at ecp.c:594 0x8029c7a
> 0x81030100
>
> It crashes properly i.e. invalid opcodes etc.
>
> There is a fair bit on google with others having gone down the same
> road, never resolved.
>
> One site which does it is socata.org but quite a few others do it.
> Probably 10% of "major name" websites cause it to crash.
>
> It may have been undiscovered for a long time, or ever, because most
> MbedTLS clients are connecting to specific private servers only.
> People aren't using it to connect to microsoft.com (which doesn't
> actually crash but the handshake returns 0x2700 which can be
> investigated).
>
> There is a Windows build of MbedTLS (v2.16.2) which seems to work in
> the crashing cases. Stepping through this in Cube IDE (32F417) it
> looks like the crash is due to a buffer being filled with random
> numbers. The guy working on this is contactable only on Monday
> afternoons so I am a bit screwed :) He said he found something about
> that buffer, or maybe a corrupted function pointer.
>
> But as I said this issue has come up before according to numerous
> online searches and maybe someone can recognise it.
>
> Hardware AES is enabled but this occurs with software AES also. No
> other 32F417 hardware crypto features are used, other than its random
> number generator.
>
> TLS is v2.16.2.
>
> Thank you in advance for any pointers.
>
> Peter