On Tue, Jul 11, 2017 at 10:19:48PM -0400, Greg Hudson wrote:

> I think the bug was introduced by commit
> 4b4036c9a6697f0101c60845e19664f64fdd0810 and is that the value of ret is
> squashed by the call to _krb5_find_capath() in tgs_build_reply().  In
> this scenario, I believe the call succeeds, but doesn't find any
> capaths, so we don't goto server_lookup, instead dropping down and going
> to out with ret still 0.  _kdc_tgs_rep() doesn't create an error reply
> if ret is 0, so the KDC sends no reply.

That looks plausible, does the below look like the right fix to you?

diff --git a/kdc/krb5tgs.c b/kdc/krb5tgs.c
index 98503812f..b6ccb68ed 100644
--- a/kdc/krb5tgs.c
+++ b/kdc/krb5tgs.c
@@ -1511,7 +1511,7 @@ tgs_build_reply(krb5_context context,
                AuthorizationData **auth_data,
                const struct sockaddr *from_addr)
 {
-    krb5_error_code ret;
+    krb5_error_code ret, ret2;
     krb5_principal cp = NULL, sp = NULL, rsp = NULL, tp = NULL, dp = NULL;
     krb5_principal krbtgt_out_principal = NULL;
     char *spn = NULL, *cpn = NULL, *tpn = NULL, *dpn = NULL, *krbtgt_out_n = 
NULL;
@@ -1677,10 +1677,12 @@ server_lookup:
        if ((req_rlm = get_krbtgt_realm(&sp->name)) != NULL) {
             if (capath == NULL) {
                 /* With referalls, hierarchical capaths are always enabled */
-                ret = _krb5_find_capath(context, tgt->crealm, our_realm,
-                                        req_rlm, TRUE, &capath, &num_capath);
-                if (ret)
+                ret2 = _krb5_find_capath(context, tgt->crealm, our_realm,
+                                         req_rlm, TRUE, &capath, &num_capath);
+                if (ret2) {
+                    ret = ret2;
                     goto out;
+                }
             }
             new_rlm = num_capath > 0 ? capath[--num_capath] : NULL;
             if (new_rlm) {

-- 
        Viktor.

Reply via email to