Parallel gss_get_mic or gss_wrap results in segfaults in krb5_k_free_key

[Greg Hudson]

On 4/19/23 01:07, Amit Kale via krbdev wrote:> We're trying to use mit 
kerberos library for NFS encryption.
> Running gss_get_mic in two threads with the same gss context results
> in following segfault.

The majority of the thread-safety work in the MIT krb5 libraries 
predates my tenure and it isn't fully documented, but it looks like 
there has never been a deliberate attempt to make GSS context handles 
safe when used simultaneously in multiple threads.  In addition to the 
use of krb5_key objects which (deliberately) aren't internally locked, 
there is also mutation of the sequence numbers and sequence states.  I 
think this hasn't come up before because most protocols using GSS 
message protection are inherently sequential, so it rarely makes sense 
to produce or process messages in parallel within a context.  But the 
GSSAPI is intended to support non-sequential protocols, so there would 
be some value in making this work.

Heimdal has internally locked context handles, and limits the critical 
section to sequence number handling.  Adding a lock to the MIT krb5 
context structure should be straightforward, but limiting the critical 
section would be harder due to the krb5_key type.