[16489] in Kerberos-V5-bugs
[krbdev.mit.edu #8881] Segfault in k5_primary_domain
daemon@ATHENA.MIT.EDU (andi@notmuch.email via RT)
Tue Mar 3 12:24:50 2020
From: "andi@notmuch.email via RT" <rt-comment@KRBDEV-PROD-APP-1.mit.edu>
In-Reply-To: <20200303100434.lnsqprj4kt3shqqg@wrt>
Message-ID: <rt-4.4.4-99345-1583256274-346.8881-4-0@mit.edu>
To: "AdminCc of krbdev.mit.edu Ticket #8881":;
Date: Tue, 03 Mar 2020 12:24:34 -0500
MIME-Version: 1.0
Reply-To: rt-comment@KRBDEV-PROD-APP-1.mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krb5-bugs-bounces@mit.edu
Tue Mar 03 12:24:34 2020: Request 8881 was acted upon.
Transaction: Ticket created by andi@notmuch.email
Queue: krb5
Subject: Segfault in k5_primary_domain
Owner: Nobody
Requestors: andi@notmuch.email
Status: new
Ticket <URL: https://krbdev.mit.edu/rt/Ticket/Display.html?id=8881 >
On NixOS we started to see segfaults when executing `gsasl` tests in our build
infrastructure that origin in the krb5 library. The particular test that
failed was the `old-simple` test with the following stack trace:
> 0x00007ffff7f433c1 in __strlen_avx2 () from /nix/store/dp9nhj3ng2hw3cfn0x0w867z0d3kp0i7-glibc-2.30/lib/libc.so.6
> #0 0x00007ffff7f433c1 in __strlen_avx2 () from /nix/store/dp9nhj3ng2hw3cfn0x0w867z0d3kp0i7-glibc-2.30/lib/libc.so.6
> #1 0x00007ffff7e75a0e in strdup () from /nix/store/dp9nhj3ng2hw3cfn0x0w867z0d3kp0i7-glibc-2.30/lib/libc.so.6
> #2 0x00007ffff7cf5f79 in k5_primary_domain () at dnsglue.c:506
> #3 0x00007ffff7cff10b in qualify_shortname (context=context@entry=0x410be0, host=host@entry=0x410610 "") at sn2princ.c:74
> #4 0x00007ffff7cff2c2 in k5_expand_hostname (context=context@entry=0x410be0, host=host@entry=0x410610 "", is_fallback=is_fallback@entry=0, canonhost_out=canonhost_out@entry=0x7fffffff8fc0) at sn2princ.c:128
> #5 0x00007ffff7cff3a1 in krb5_expand_hostname (context=context@entry=0x410be0, host=host@entry=0x410610 "", canonhost_out=canonhost_out@entry=0x7fffffff8fc0) at sn2princ.c:164
> #6 0x00007ffff7cff5f6 in krb5_sname_to_principal (context=0x410be0, hostname=0x410610 "", sname=0x40f5b0 "", type=type@entry=3, princ_out=princ_out@entry=0x7fffffff9088) at sn2princ.c:219
> #7 0x00007ffff7d8d6a8 in krb5_gss_import_name (minor_status=0x7fffffffb2b4, input_name_buffer=0x40f480, input_name_type=0x40f640, output_name=0x7fffffffb1c0) at import_name.c:166
> #8 0x00007ffff7d789bc in gssint_import_internal_name (minor_status=minor_status@entry=0x7fffffffb2b4, mech_type=0x40e290, union_name=union_name@entry=0x40fad0, internal_name=internal_name@entry=0x7fffffffb1c0) at g_glue.c:400
> #9 0x00007ffff7d74661 in gss_add_cred_from (minor_status=minor_status@entry=0x7fffffffb2b4, input_cred_handle=0x410bb0, desired_name=desired_name@entry=0x40fad0, desired_mech=<optimized out>, cred_usage=cred_usage@entry=2, initiator_time_req=initiator_time_req@entry=0, acceptor_time_req=0, cred_store=0x0, output_cred_handle=0x0, actual_mechs=0x0, initiator_time_rec=0x0, acceptor_time_rec=0x0) at g_acquire_cred.c:512
> #10 0x00007ffff7d74cbb in gss_acquire_cred_from (minor_status=minor_status@entry=0x7fffffffb394, desired_name=0x40fad0, time_req=time_req@entry=0, desired_mechs=desired_mechs@entry=0x0, cred_usage=cred_usage@entry=2, cred_store=cred_store@entry=0x0, output_cred_handle=0x40d740, actual_mechs=0x0, time_rec=0x0) at g_acquire_cred.c:190
> #11 0x00007ffff7d74dd1 in gss_acquire_cred (minor_status=minor_status@entry=0x7fffffffb394, desired_name=<optimized out>, time_req=time_req@entry=0, desired_mechs=desired_mechs@entry=0x0, cred_usage=cred_usage@entry=2, output_cred_handle=output_cred_handle@entry=0x40d740, actual_mechs=0x0, time_rec=0x0) at g_acquire_cred.c:107
> #12 0x00007ffff7fc32c6 in _gsasl_gssapi_server_start (sctx=<optimized out>, mech_data=0x40dfc8) at server.c:98
> #13 0x00007ffff7fb317e in setup (ctx=ctx@entry=0x40a6b0, mech=mech@entry=0x7ffff7fc7445 "GSSAPI", sctx=sctx@entry=0x40dfb0, n_mechs=n_mechs@entry=13, mechs=mechs@entry=0x40d760, clientp=clientp@entry=0) at xstart.c:69
> #14 0x00007ffff7fb31f2 in start (ctx=ctx@entry=0x40a6b0, mech=0x7ffff7fc7445 "GSSAPI", sctx=sctx@entry=0x7fffffffb480, n_mechs=13, mechs=0x40d760, clientp=clientp@entry=0) at xstart.c:94
> #15 0x00007ffff7fb324f in gsasl_server_start (ctx=ctx@entry=0x40a6b0, mech=<optimized out>, sctx=sctx@entry=0x7fffffffb480) at xstart.c:139
> #16 0x00007ffff7fb2fd2 in _gsasl_listmech (ctx=0x40a6b0, mechs=0x40d760, n_mechs=13, out=out@entry=0x7fffffffb4e0, clientp=clientp@entry=0) at listmech.c:44
> #17 0x00007ffff7fb30b8 in gsasl_server_mechlist (ctx=<optimized out>, out=out@entry=0x7fffffffb4e0) at listmech.c:95
> #18 0x00007ffff7fb3f39 in gsasl_server_listmech (ctx=<optimized out>, out=out@entry=0x7fffffffb540 "ANONYMOUS EXTERNAL LOGIN PLAIN SECURID DIGEST-MD5 CRAM-MD5 SCRAM-SHA-1 SAML20 OPENID20 GSSAPI GS2-KRB5", outlen=outlen@entry=0x7fffffffb538) at obsolete.c:94
> #19 0x0000000000402dbf in doit () at old-simple.c:438
> #20 0x0000000000403a7e in main (argc=<optimized out>, argv=0x7fffffffd668) at utils.c:140
After looking at the implementation of `k5_primary_domain` it became
obvious that the result of the res_ninit(3) call is never validated. The
call doesn't fail but the `res_state` structure doesn't seem to be fully
populated as expected. At least `h.dnsrch[0]` is NULL leading to
`strdup` segfaulting the application.
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
