Parallel gss_get_mic or gss_wrap results in segfaults in krb5_k_free_key

Amit Kale amit.kale at cohesity.com
Wed Apr 19 01:07:33 EDT 2023


Greetings MIT Kerberos library developers,

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.

    @     0x7fb0ec09f62b krb5_k_free_key
    @     0x7fb0ec09b0c9 krb5int_dk_checksum
    @     0x7fb0ec09fddd krb5_k_make_checksum
    @     0x7fb0f7042478 gss_krb5int_make_seal_token_v3
    @     0x7fb0f7040b67 kg_seal
    @     0x7fb0f70412fa krb5_gss_get_mic
    @     0x7fb0f7032be8 gss_get_mic

Similarly gss_wrap parallel execution also leads to following segfault
    @     0x7fb0ef957131 je_free_default
    @     0x7fb0ec09f63c krb5_k_free_key
    @     0x7fb0ec09df24 krb5int_dk_encrypt
    @     0x7fb0ec09cfaa krb5_k_encrypt
    @     0x7fb0f7042676 gss_krb5int_make_seal_token_v3
    @     0x7fb0f7040b67 kg_seal
    @     0x7fb0f70412d2 krb5_gss_wrap
    @     0x7fb0f7032307 gss_wrap

We have following analysis of this issue.

Each key krb5_key->derived contains a list of previously derived keys. This
forms the derived key cache. This derived key cache is not thread safe. There
are no locks. That's the reason why we hit these segfaults.

If this analysis is correct, we'll post a patch that attempts to fix it.

src/tests/gss-threads/README mentions the following -
[Out of date; needs updating for thread safety test support.  -- KR 2005-02-09]
If adding thread safety tests in this code will be helpful, we're open
to doing that as well.

Look forward to hearing from you.
Thanks.
-Amit


More information about the krbdev mailing list