This is one of the Venustech AD-LAB alleged vulnerabilities. CVE-2007-5901 http://bugs.gentoo.org/show_bug.cgi?id=199214 This bug is consists of freeing a non-heap pointer, and is not a practical vulnerability due to the extreme difficulty of exploitation. In src/lib/gssapi/mechglue/g_initialize.c, the function gss_indicate_mechs() can make the call free(mechSet), which is erroneous because "mechSet" is a pointer to type "gss_OID_set" passed in by the caller of gss_indicate_mechs() and the dereferenced "*mechSet" is where the pointer to allocated memory is assigned. 201 /* still need to copy each of the oid elements arrays */ 202 for (i = 0; i < (*mechSet)->count; i++) { 203 curItem = &((*mechSet)->elements[i]); 204 curItem->elements = 205 (void *) malloc(g_mechSet.elements[i].length); 206 if (curItem->elements == NULL) { 207 (void) k5_mutex_unlock(&g_mechSetLock); 208 /* 209 * must still free the allocated elements for 210 * each allocated gss_OID_desc 211 */ 212 for (j = 0; j < i; j++) { 213 free((*mechSet)->elements[j].elements); 214 } 215 free((*mechSet)->elements); 216 free(mechSet); 217 *mechSet = NULL; 218 return (GSS_S_FAILURE); 219 } 220 g_OID_copy(curItem, &g_mechSet.elements[i]); 221 } If the allocation of (*mechSet)->elements fails, the erroneous call of free(mechSet) occurs, freeing a pointer which probably points into the stack frame of the caller. In order to successfully exploit this vulnerability, an attacker would have to cause a malloc() failure to occur at precisely the right time: almost immediately after a different malloc() call has succeeded.