Looking at the source to def_realm - this code either sets or returns
the default realm for the application - which in turn sets to pointer 
in the krb5_context.  No locking is present in the code.

krb5_get_default_realm will return a copy of the krb5_context default 
realm if set.  If not, it will try to parse the libdefaluts section of 
the profile, followed by a dns lookup.  Once the variable is set - the 
code will malloc the return value.

On the flip side, krb5_set_default_realm - will free the memory (if 
set) of the default realm and then allocating new.

I can see a potential race condition in the code - where the context 
default realm is set - and then is no more...

The chance of hitting this is so slim - but I thought it should be 
mentioned.