There are two mutex locking issues that Roland Dowdeswell noticed in
authorJeffrey Altman <jaltman@secure-endpoints.com>
Mon, 21 Jul 2008 19:43:21 +0000 (19:43 +0000)
committerJeffrey Altman <jaltman@secure-endpoints.com>
Mon, 21 Jul 2008 19:43:21 +0000 (19:43 +0000)
the memory ccache.  The first one is in cc_memory.c:krb5_mcc_initialize().
When it is free(3)ing the existing credentials it does not lock the
data structures and hence two separate threads can run into issues.

The same problem exists in cc_memory.c:krb5_mcc_destroy().

ticket: 5895
tags: pullup

git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@20555 dc483132-0cff-0310-8789-dd5450dbe970

src/lib/krb5/ccache/cc_memory.c

index d5c0493baf0bdf3f97d00f86043ec24a7986eeef..3427c7582403531af4e8b739e07a40c5333bb5e2 100644 (file)
@@ -139,10 +139,18 @@ krb5_error_code KRB5_CALLCONV
 krb5_mcc_initialize(krb5_context context, krb5_ccache id, krb5_principal princ)
 {
     krb5_error_code ret; 
+    krb5_mcc_data *d;
+
+    d = (krb5_mcc_data *)id->data;
+    ret = k5_mutex_lock(&d->lock);
+    if (ret)
+        return ret;
 
     krb5_mcc_free(context, id);
     ret = krb5_copy_principal(context, princ,
                              &((krb5_mcc_data *)id->data)->prin);
+
+    k5_mutex_unlock(&d->lock);
     if (ret == KRB5_OK)
         krb5_change_cache();
     return ret;
@@ -209,8 +217,13 @@ krb5_mcc_destroy(krb5_context context, krb5_ccache id)
     }
     k5_mutex_unlock(&krb5int_mcc_mutex);
 
+    err = k5_mutex_lock(&d->lock);
+    if (err)
+        return err;
+
     krb5_mcc_free(context, id);
     krb5_xfree(d->name);
+    k5_mutex_unlock(&d->lock);
     k5_mutex_destroy(&d->lock);
     krb5_xfree(d); 
     krb5_xfree(id);