Re: Parallel gss_get_mic or gss_wrap results in segfaults in krb5_k_free_key

On Wed, Apr 19, 2023 at 01:52:52PM -0400, Greg Hudson wrote:
> 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.

In OpenJDK 21 this will almost certainly cause crashes in Java apps
using the new green thread scheme.

Nico
-- 
_______________________________________________
krbdev mailing list             [email protected]
https://mailman.mit.edu/mailman/listinfo/krbdev