Parallel gss_get_mic or gss_wrap results in segfaults in krb5_k_free_key

[Amit Kale]

Thanks for this info. It appears that we'll need to do some
investigation to figure out the extent of this issue. We're doing more
testing and will continue to post our findings and
suggestions/patches.
-Amit

On Wed, Apr 19, 2023 at 11:22 PM Greg Hudson <ghudson at mit.edu> wrote:
>
> 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.