Crash in gss_get_mic in mech_eap on Debian 8

[Dan Breslau]

[Copied from email I sent to the Moonshot list] :

Hi, all,

I'm seeing a weird crash in gss-server on Debian 8. After I installed debugging symbols for libgssapi-krb5, I get this stack trace:

    #0 kg_seal_iov (minor_status=0x7fffffffe0b8, context_handle=0x7fffffffe000, conf_req_flag=-7936, qop_req=0, conf_state=0x606060, iov=0x0, iov_count=2,
        toktype=257) at ../../../../src/lib/gssapi/krb5/k5sealiov.c:287
    #1 0x00007ffff7bbc98a in krb5_gss_get_mic_iov (minor_status=<optimized out>, context_handle=<optimized out>, qop_req=<optimized out>,
        iov=<optimized out>, iov_count=<optimized out>) at ../../../../src/lib/gssapi/krb5/k5sealiov.c:540
    #2 0x00007ffff5c0100e in gss_get_mic (minor=0x7fffffffe0b8, ctx=0x66a190, qop_req=0, message_buffer=0x7fffffffe100, message_token=0x7fffffffe110)
        at get_mic.c:104
    #3 0x00007ffff7bad251 in gss_get_mic (minor_status=0x7fffffffe0b8, context_handle=0x606060, qop_req=0, message_buffer=0x7fffffffe100,
        msg_token=0x7fffffffe110) at ../../../../src/lib/gssapi/mechglue/g_sign.c:101
    #4 0x00000000004023ec in ?? ()
    #5 0x0000000000401a77 in ?? ()
    #6 0x00007ffff68d3b45 in __libc_start_main (main=0x4016b0, argc=3, argv=0x7fffffffe2e8, init=<optimized out>, fini=<optimized out>,
        rtld_fini=<optimized out>, stack_end=0x7fffffffe2d8) at libc-start.c:287
    #7 0x0000000000401baf in ?? ()

Frame #2 is in mech_eap/get_mic.c. At line 104 of that function, we have:

    major = gss_get_mic_iov(minor, (gss_ctx_id_t)ctx, qop_req, iov, 2);

mech_eap/get_mic.c defines a function named gss_get_mic_iov. I'd expect that to be the function that's being called here. But no... from that line, control instead jumps to a method in libgssapi_krb5 that's also named gss_get_mic_iov. The crash happens shortly thereafter.

If I rename the local gss_get_mic_iov function to MY_gss_get_mic_iov, and change the call at line 104 to match, then it doesn't crash. I don't know that this works, as such, but it doesn't crash. And that's where I'm stuck: I'm around 90% sure that that call at line 104 of get_mic.c is really trying to call the local function. But I don't know. If it really wants to call the gssapi_krb5 version of the function, then it seems to be doing it wrong: I think the gssapi_krb5 function by that name expects things to be in the ctx object that aren't there -- particularly an inner context object -- and this is why it winds up crashing.

I do know that libgssapi_krb5 calls into mech_eap dynamically, and one of the methods it looks for is named gss_get_mic_iov. When I renamed gss_get_mic_iov to MY_gss_get_mic_iov, I also added a wrapper with the name gss_get_mic_iov so that (at least in theory) the linkage from libgssapi_krb5 would remain the same. But it looks like gss_get_mic_iov is never called during these tests.
Lastly, gss_get_mic_iov was added to mech_eap/get_mic.c in rev 93039967, which was committed by Luke Howard on Sun Aug 30 16:41:12 2015 -- just a couple of days after the latest Debian mech_eap package, 0.9.5, was added to the Debian Moonshot repository. If I build locally with rev 93039967, I get this crash. If I build locally with rev 93039967^ , it doesn't crash.

So, Luke: Am I right in guessing that the call to gss_get_mic_iov is supposed to go to the local definition for that function? And, anyone -- would you expect dynamically-loaded libraries to prefer binding to symbols defined in shared libraries (e.g., the gss_get_mic_iov defined in libgssapi_krb5) to their own defined symbols?

----

Luke Howard responded:
In answer to your first question: yes. I have seen something similar happen but it was in a slightly different situation. Not sure why this is happening. How about the attached patch? (It does violate a coding convention in mech_eap, where only top-level gss_XXX routines acquire the lock, but maybe it’s OK…)

[Dan Breslau (dbreslau)]

This was fixed in rev 1.0.1 of moonshot-gss-eap, using the patch that Luke provided.