Project

General

Profile

Actions

Bug #4467

open

kadmind: segfault in acquire_accept_cred+0x140()

Added by Marcel Telka over 7 years ago. Updated over 5 years ago.

Status:
In Progress
Priority:
Normal
Assignee:
-
Category:
cmd - userland programs
Start date:
2014-01-14
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

Description

I configured KDC using kdcmgr. At the end of the kdcmgr script the kadmin smf service is enabled. Once the service has been enabled the kadmind segfaulted:

> ::status
debugging core file of kadmind (32-bit) from kdc
file: /usr/lib/krb5/kadmind
initial argv: /usr/lib/krb5/kadmind
threading model: native threads
status: process terminated by SIGSEGV (Segmentation Fault), addr=0
> ::stack
mech_krb5.so.1`acquire_accept_cred+0x140(8084680, 8047b54, 8063ab0, 8084b64, 
8084b40, 0)
mech_krb5.so.1`krb5_gss_acquire_cred+0x2a6(8047b54, 8063ab0, 0, 0, 2, 8047a50)
mech_krb5.so.1`k5glue_acquire_cred+0x30(0, 8047b54, 8063ab0, 0, 0, 2)
libgss.so.1`gss_add_cred+0x1db(8047b54, 80ef2e8, 8061ce8, 8080560, 2, 0)
libgss.so.1`gss_acquire_cred+0x11c(8047b54, 8061ce8, 0, 8047b60, 2, 80ef1c4)
rpcsec.so.1`__rpc_gss_set_svc_name+0x1fa(805ecfa, 805ebfa, 0, 840, 2, 0)
libnsl.so.1`rpc_gss_set_svc_name+0x34(805ecfa, 805ebfa, 0, 840, 2)
main+0x10ec(8047ddc, fef6f7c8, 8047e1c, 805509f, 1, 8047e28)
_start+0x83(1, 8047ed0, 0, 8047ee6, 8047f02, 8047f13)
>

The core file is available at http://telka.sk/illumos/4467/core.kadmind.0.1389686420.


Files

kdb.patch (1.28 KB) kdb.patch Dale Ghent, 2015-04-01 09:00 PM

Related issues

Has duplicate illumos gate - Bug #9739: kerberos kadmind crashed in openindiana hipster 2018/04Rejected2018-08-16

Actions
Actions #1

Updated by Marcel Telka over 7 years ago

At the beginning of acquire_accept_cred() the krb5_kt_resolve() was called because krb5_gss_keytab is already initialized to "KDB:".

173   if (krb5_gss_keytab != NULL) {
174      code = krb5_kt_resolve(context, krb5_gss_keytab, &kt);
175      k5_mutex_unlock(&gssint_krb5_keytab_lock);
176   } else {
177      k5_mutex_unlock(&gssint_krb5_keytab_lock);
178      code = krb5_kt_default(context, &kt);
179   }

The aim of krb5_kt_resolve() is to initialize kt. In this particular case the kt is initialized via this code in krb5_kt_resolve() - the kt is called ktid here:

173    for (; tlist; tlist = tlist->next) {
174    if (strcmp (tlist->ops->prefix, pfx) == 0) {
175        free(pfx);
176        return (*tlist->ops->resolve)(context, resid, ktid);
177    }
178    }

and krb5_ktkdb_resolve() is called because *tlist->ops->resolve points to it. The krb5_ktkdb_resolve() initializes both ops and magic of the ktid, but leaves data uninitialized (usually NULL).

Back to acquire_accept_cred(), so we now have half-initialized kt. Later this code is executed:

187    if (desired_name != GSS_C_NO_NAME) {
188        princ = (krb5_principal) desired_name;
189        if ((code = krb5_kt_get_entry(context, kt, princ, 0, 0, &entry))) {
190        if (code == KRB5_KT_NOTFOUND) {
191            char *s_name;
192            if (krb5_unparse_name(context, princ, &s_name) == 0) {
193            krb5_set_error_message(context, KG_KEYTAB_NOMATCH,
194                    dgettext(TEXT_DOMAIN,
195                        "No principal in keytab ('%s') matches desired name %s"),
196                    KTFILENAME(kt),
197                    s_name);

In a case the krb5_kt_get_entry() fails with KRB5_KT_NOTFOUND, we still have kt->data uninitialized. At line 196 the KTFILENAME macro tries to dereference kt->data and segfaults:

70#define KTFILENAME(id) (((krb5_ktfile_data *)(id)->data)->name)
Actions #2

Updated by Dale Ghent over 6 years ago

The attached patch seems to clear up the null ptr deref in kadmind

Actions #3

Updated by Marcel Telka over 5 years ago

  • Status changed from New to In Progress
Actions #4

Updated by Marcel Telka about 3 years ago

  • Has duplicate Bug #9739: kerberos kadmind crashed in openindiana hipster 2018/04 added
Actions

Also available in: Atom PDF