Hide Forgot
Description of problem: In gp_add_krb5_cred, the variable cred_store is allocated as a local variable (type gss_key_value_set_desc). gss_key_value_set_desc is a structure containing a count and a pointer (elements) to what will become an array of structures (gss_key_value_element_desc) containing more pointers (key and value). gp_add_krb5_cred calls (among other things) gp_get_cred_environment, which will allocate memory for the array elements, and fill it with pointers to values that it also allocates for the pointers key and value. Now, a pointer to cred_store is passed two more times from gp_add_krb5_cred, both times to gss_acquire_cred_from. I didn't track down all of the uses inside gss_acquire_cred_from (some were following pointers to functions that I didn't really want to try to figure out how to track down), but the ones I did track down did not attempt to free the memory allocated in the cred_store, and there were certainly code paths through gss_acquire_cred_from which absolutely did not free this memory. Anyway, gp_add_krb5_cred never frees any of the memory allocated to the fill in the various layers of pointers allocated and tracked with cred_store before exiting. Here's the section of valgrind output that lead me to this: ==24113== 259,728 (148,416 direct, 111,312 indirect) bytes in 4,638 blocks are definitely lost in loss record 82 of 85 ==24113== at 0x4C2B974: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==24113== by 0x408063: gp_get_cred_environment (gp_creds.c:331) ==24113== by 0x408063: gp_add_krb5_creds (gp_creds.c:461) ==24113== by 0x40DD15: gp_accept_sec_context (gp_rpc_accept_sec_context.c:79) ==24113== by 0x40ADC0: gp_rpc_execute (gp_rpc_process.c:343) ==24113== by 0x40ADC0: gp_rpc_process_call (gp_rpc_process.c:400) ==24113== by 0x4073CB: gp_handle_query (gp_workers.c:447) ==24113== by 0x4073CB: gp_worker_main (gp_workers.c:401) ==24113== by 0x6822DC4: start_thread (pthread_create.c:308) ==24113== by 0x6B2DCEC: clone (clone.S:113) Unless I've messed up in reading this (which is always a possibility), this bug would definitely cause both direct and indirect memory leaks that would show up in that loss record. Version-Release number of selected component (if applicable): 0.4.1-13.el7 How reproducible: 100% Steps to Reproduce: 1. Look at the code. 2. See the bug. 3. Slap self in forehead. Beating head on desk, weeping and wailing all still optional. Actual results: Memory leak. Expected results: No memory leak. Additional info:
Couple things I forgot to mention: 1) Of course, somewhere in those calls to gss_acquire_cred_from we could be just copying pointers (instead of making copies of the data that are pointed to by those pointers and setting up pointers to those copies). I couldn't see where this could be happening, but then again, I didn't track down those function pointers to see if those might be doing it. I'll do that. 2) If #1 up there checks out OK, I'm thinking the fix could probably be something simple like adding: if (cred_store.elements) free_cred_store_elements (&cred_store); to the code after the "done" label in the gp_add_krb5_cred function. I'm not seeing any direct returns (all returns seem to be done through a "goto done;") in that function. I'm going to try to track down those function pointers and see what they're doing. That's starting to bother me, now.
Yeah, I got lost trying to figure out what functions would be in those function pointers. I'm going to leave that to someone who's already familiar with the code, and probably already knows if they are doing any freeing in there or copying any pointers without copying the data or not. I doubt very seriously they are. I've spent enough time on this particular one for now. Sorry.
Verified using GSSProxy :: gssproxy-0.7.0-3.el7.x86_64 Marking BZ as verified as sanityonly.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:2033