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 Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders