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

Reply via email to