Ticket History #6647: Memory leak in kdc

Set up a simple kdc (1.8 alpha trunk) - configure w/ --disable-pkinit
(too much cruft). Add a principal - no special flags - pretty default
using as reference the krb5.conf and kdc.conf in config-files subdir.

Run kdc w/ valgrind w/o forking

kinit as client

See a per request memory leak on server...

==28880== 48 bytes in 3 blocks are indirectly lost in loss record 3 of 10
==28880== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==28880== by 0x8055B0C: kdc_handle_protected_negotiation
(kdc_util.c:2679)
==28880== by 0x8059F12: return_enc_padata (kdc_preauth.c:3125)
==28880== by 0x804D2E6: process_as_req (do_as_req.c:625)
==28880== by 0x804C0C0: dispatch (dispatch.c:99)
==28880== by 0x805D89D: process_packet (network.c:1298)
==28880== by 0x805E6C1: service_conn (network.c:1638)
==28880== by 0x805E9E9: listen_and_process (network.c:1729)
==28880== by 0x805B98D: main (main.c:939)
==28880==
==28880== 48 bytes in 3 blocks are indirectly lost in loss record 4 of 10
==28880== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==28880== by 0x8055BE4: kdc_handle_protected_negotiation
(kdc_util.c:2696)
==28880== by 0x8059F12: return_enc_padata (kdc_preauth.c:3125)
==28880== by 0x804D2E6: process_as_req (do_as_req.c:625)
==28880== by 0x804C0C0: dispatch (dispatch.c:99)
==28880== by 0x805D89D: process_packet (network.c:1298)
==28880== by 0x805E6C1: service_conn (network.c:1638)
==28880== by 0x805E9E9: listen_and_process (network.c:1729)
==28880== by 0x805B98D: main (main.c:939)

I believe the issue is in processes_as_req... return_enc_padata will
fills in the reply_encpart->enc_padata.

In process_as_req the reply_encpart individual parts are freed based on
who owns the memory. I believe there is a missing free of the enc_padata.

I would fix this - but would prefer another set of eyes on it...

Of course, reply (the non enc-part) is also treated as a container full
of aliases, except for reply.padata, which is treated as owned memory
and initialized/cleaned up. So, fragile as that is, perhaps it's more
consistent with the current design (such as it is) of the function to
treat reply_encpart.enc_padata as owned memory similarly.

Also a less invasive fix for 1.8.

Should be fixed in r23714.

On 2/10/2010 2:30 PM, Greg Hudson via RT wrote:
I have confirmed that in my simple test case - the leak is fixed.

Ezra