Skip Menu |

Subject: Possible thread safety issue in lib/krb5/os/def_realm.c
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
The default_realm code adjusts fields in the context, which isn't required to have locking in
our current approach.