I searched for usage of EVP_MD_CTX_free()/EVP_MD_CTX_new() and found a similar
memory leak in the generate_Ku() function within snmplib/keytools.c. I had to
craft up a client app to force this error path, but Valgrind did confirm it:
==4091== 17,328 bytes in 361 blocks are definitely lost in loss record 696 of
704
==4091== at 0x4C29BE3: malloc (vg_replace_malloc.c:299)
==4091== by 0x52223B7: CRYPTO_malloc (in /usr/lib64/libcrypto.so.1.0.2k)
==4091== by 0x52DDB06: EVP_MD_CTX_create (in /usr/lib64/libcrypto.so.1.0.2k)
==4091== by 0x4E9885D: generate_Ku (keytools.c:186)
==4091== by 0x40171F: asynchronous (leaktest.c:276)
==4091== by 0x400FE7: main (leaktest.c:356)
My proposed patch against 5.8 to fix the leak:
diff -ru net-snmp-5.8/snmplib/keytools.c net-snmp-5.8-new/snmplib/keytools.c
--- net-snmp-5.8/snmplib/keytools.c 2018-07-16 09:33:40.000000000 -0500
+++ net-snmp-5.8-new/snmplib/keytools.c 2018-10-10 12:45:16.054237424 -0500
@@ -186,11 +186,15 @@
ctx = EVP_MD_CTX_create();
#else
ctx = malloc(sizeof(*ctx));
- if (!EVP_MD_CTX_init(ctx))
- return SNMPERR_GENERR;
+ if (!EVP_MD_CTX_init(ctx)) {
+ rval = SNMPERR_GENERR;
+ goto generate_Ku_quit;
+ }
#endif
- if (!EVP_DigestInit(ctx, hashfn))
- return SNMPERR_GENERR;
+ if (!EVP_DigestInit(ctx, hashfn)) {
+ rval = SNMPERR_GENERR;
+ goto generate_Ku_quit;
+ }
#elif NETSNMP_USE_INTERNAL_CRYPTO
#ifndef NETSNMP_DISABLE_MD5
After applying the patch, Valgrind shows no memory leaks.
Comments or questions are welcome.
-Drew
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
