[krbdev.mit.edu #7981] Minor memory leak in GSS-API mechanism initialization

[Russ Allbery <rra@stanford.edu> via RT]

valgrind testing with WebAuth surfaced the following minor memory leak
with MIT Kerberos 1.12.1:

==13031== 8 bytes in 1 blocks are definitely lost in loss record 1 of 566
==13031==    at 0x4028B4C: malloc (vg_replace_malloc.c:291)
==13031==    by 0x427C05C: glob (glob.c:452)
==13031==    by 0x43C4EED: updateMechList (g_initialize.c:447)
==13031==    by 0x43C5B14: gssint_select_mech_type (g_initialize.c:513)
==13031==    by 0x43C17B5: gss_init_sec_context (g_init_sec_context.c:139)
==13031==    by 0x43A6610: ??? (in
/usr/lib/i386-linux-gnu/libremctl.so.1.1.0)
==13031==    by 0x43A4C13: remctl_open (in
/usr/lib/i386-linux-gnu/libremctl.so.1.1.0)
==13031==    by 0x403FE59: remctl_generic (userinfo.c:881)
==13031==    by 0x4040BDC: webauth_user_info (userinfo.c:1051)
==13031==    by 0x8049A3F: test_userinfo_calls (userinfo-t.c:99)
==13031==    by 0x804ADCA: main (userinfo-t.c:449)

The relevant code in Git is:

        if (glob(MECH_CONF_PATTERN, 0, NULL, &globbuf) == 0) {
                for (path = globbuf.gl_pathv; *path != NULL; path++)
                        load_if_changed(*path, g_confFileModTime, &highest);
                globfree(&globbuf);
        }

The problem with this code is that the memory allocation in the glob()
function is unconditional, even if glob() fails, so you always have to
call globfree(), not just on success.  From POSIX:

    Note that gl_pathc and gl_pathv have meaning even if glob() fails.
This allows glob() to report partial results in the event of an error.
However, if gl_pathc is 0, gl_pathv is unspecified even if glob() did
not return an error.

Some additional interesting discussion is here:

https://lists.debian.org/debian-glibc/2004/08/msg00139.html