Crash in gss_get_mic in mech_eap on Debian 8
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Project Moonshot |
Fix Released
|
High
|
Dan Breslau |
Bug Description
[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_
#1 0x00007ffff7bbc98a in krb5_gss_
#2 0x00007ffff5c0100e in gss_get_mic (minor=
at get_mic.c:104
#3 0x00007ffff7bad251 in gss_get_mic (minor_
#4 0x00000000004023ec in ?? ()
#5 0x0000000000401a77 in ?? ()
#6 0x00007ffff68d3b45 in __libc_start_main (main=0x4016b0, argc=3, argv=0x7fffffff
#7 0x0000000000401baf in ?? ()
Frame #2 is in mech_eap/get_mic.c. At line 104 of that function, we have:
major = gss_get_
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…)
This was fixed in rev 1.0.1 of moonshot-gss-eap, using the patch that Luke provided.