SE05x-MW-v04.03.00 openssl 3.x memory leaks and overall openssl support state

[bboozzoo]

We are using the SE05x middleware libraries configured with OpenSSL for host crypto (-DPTMW_HostCrypto=OPENSSL -DPTMW_OpenSSL=3_0). I have some code which sets up an authenticated session using AES keys and observe continuous memory leaks. Digging into this with valgrind I was able to find a memory leak in `sss_host_mac_init()`. I was then able to identify that the leak would occur on each APDU, as supported by the valgrind backtrace:

==4576== 144,401 (456 direct, 143,945 indirect) bytes in 1 blocks are definitely lost in loss record 1,961 of 1,961
==4576==    at 0x486551C: malloc (vg_replace_malloc.c:381)
==4576==    by 0x4A65507: CRYPTO_zalloc (in /usr/lib/libcrypto.so.3)
==4576==    by 0x4A60B43: OSSL_LIB_CTX_new (in /usr/lib/libcrypto.so.3)
==4576==    by 0x4BC237: sss_openssl_mac_context_init (fsl_sss_openssl_apis.c:2965)
==4576==    by 0x4D9DEB: nxpSCP03_Decrypt_ResponseAPDU (nxScp03_Com.c:154)
==4576==    by 0x4D946B: se05x_DeCrypt (se05x_tlv.c:727)
==4576==    by 0x4BD8F3: sss_se05x_TXn (fsl_sss_se05x_apis.c:7011)
==4576==    by 0x4D16CB: Se05x_API_ReadObject (se05x_APDU_impl.h:769)
==4576==    by 0x4BE25B: sss_se05x_session_prop_get_au8 (fsl_sss_se05x_apis.c:856)

I patched the problem locally (I will submit the patch once I get a sign-off from the management), but given the severity this would have a reasonable impact on any long running process.

Which brings me to the following questions:

• is the openssl host crypto supported and actively tested?
• If so which version of openssl?
• if now, should I switch to mbedtls?

[bboozzoo]

@Kan_Lione more question, as this hasn't been answered. Is the openssl host crypto build configuration actively tested and maintained?

[Kan_Li]

Hi @bboozzoo ,

Thanks for the report! Would you please tell me the platform used in your test as well as the example tested with valgrind? I will try to reproduce it here.

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[bboozzoo]

The middleware is built with the following settings:
-DCMAKE_BUILD_TYPE=RelWithDebInfo \
-DWithSharedLIB=OFF \
-DPTMW_Host=iMXLinux \
-DPTMW_HostCrypto=OPENSSL -DPTMW_OpenSSL=3_0 \
-DPTMW_SCP=SCP03_SSS -DPTMW_SE05X_Ver=03_XX \
-DPTMW_SMCOM=T1oI2C -DPTMW_Applet=SE05X_C -DPTMW_SE05X_Auth=None \
-DOPENSSL_ROOT_DIR=${WORKDIR}/recipe-sysroot/usr/ \

I did not try to reproduce this with any of the examples. This was captured when debugging our app. For obvious reasons I cannot share the code, but I can git you some pointers. Looking into the openssl sss wrappers, this code specifically: https://github.com/NXP/plug-and-trust/blob/cc00ff155507f38b241aa8c8f700b8f2da9682f2/sss/src/openssl/... the library_context from OSSL_LIB_CTX_new is never released and leaks, same for mac obtained through EVP_MAC_fetch (which holds a reference, and then another reference is taken by EVP_MAC_CTX_new(). As mentioned earlier, this is called in the context of every APDU.

Can you comment on whether you are actively testing/maintaining the openssl hostcrypto?

[Kan_Li · Accepted solution]

Hi @bboozzoo ,

It looks like the issue is actually in the SCP implementation. When the session fails, the required clean up SSS openssl calls are not executed, I have reported to R&D team, and this will be fixed in the next release.

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------