Hi,

> Otherwise we could update to 2.28.1 (and spend time doing that, plus back-editing various patches) and find that it doesn't fix it.

Absolutely, but that wasn't the reason why I was recommending you use a maintained version. There are mainly two reasons.

Firstly, there have been 43 entries in the Security section of ChangeLog  between the release you're using and 2.28.1. Are you confident none of those vulnerabilities affect you? Have you reviewed those entries against your use case & threat model ? If you haven't, perhaps an attacker has...

Secondly, what about the next vulnerabilities that are going to be disclosed as we fix them in future 2.28.x? If one of them impacts your code in a severe way, you'll have to do an emergency upgrade from 2.16.2 to 2.28.x, which as you point out can be non-trivial work, while upgrading from 2.28.x to 2.28.x+1 is usually much less work.

> Updating to v3 is reportedly a LOT of work.

From: Peter <peter@peter2000.co.uk>
Sent: 07 December 2022 12:57
To: Manuel Pegourie-Gonnard <Manuel.Pegourie-Gonnard@arm.com>
Cc: mbed-tls@lists.trustedfirmware.org <mbed-tls@lists.trustedfirmware.org>
Subject: Re: [mbed-tls] MbedTLS crashes with some websites in mbedtls_mpi_free()
 
Hello Manuel,

I am hoping somebody may recognise the issue.

Otherwise we could update to 2.28.1 (and spend time doing that, plus
back-editing various patches) and find that it doesn't fix it.

Updating to v3 is reportedly a LOT of work.

This is almost certainly not a security vulnerability.

Apart from this issue, the MbedTLS code has been working solidly for a
couple of years.

Interestingly it happens only on the ST port of MbedTLS, not on a
Windows compilation of MbedTLS.

Regards,

Peter

>Hi Peter,
>
>Mbed TLS v2.16.2 is no longer maintained. I would strongly recommend you, and in fact everyone, to use a maintained version of Mbed TLS. Currently the two maintained versions are 2.28.1 (2.28.x is the current LTS branch) and 3.2.1 (3.x is where new features arrive). Versions that are no longer maintained have publicly known security vulnerabilities.
>
>(I didn't analyze the specific problem you're facing so I can't say if this is something that has been fixed in the meantime.)
>
>Best regards,
>Manuel.
>
>________________________________
>From: Peter via mbed-tls <mbed-tls@lists.trustedfirmware.org>
>Sent: 06 December 2022 17:25
>To: mbed-tls@lists.trustedfirmware.org <mbed-tls@lists.trustedfirmware.org>
>Subject: [mbed-tls] MbedTLS crashes with some websites in mbedtls_mpi_free()
>
>
>
>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