| 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
mentioned.
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.