#1328 curl crashes with a SEGFAULT on FreeBSD with GSS-API calls

[Michael Osipov]

l$ bin/curl -V
curl 7.35.0 (i386-unknown-freebsd9.2) libcurl/7.35.0 OpenSSL/1.0.1f zlib/1.2.8 libidn/1.28 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: GSS-Negotiate IDN Largefile NTLM NTLM_WB SSL libz TLS-SRP

$ bin/curl --verbose --negotiate -u : http://hostname:8080/manager/html
Hostname was NOT found in DNS cache
Trying 1.2.3.4...
* Connected to hostname (1.2.3.4) port 8080 (#0)

GET /manager/html HTTP/1.1
User-Agent: curl/7.35.0
Host: hostname:8080
Accept: /

< HTTP/1.1 401 Unauthorized
* Server Apache-Coyote/1.1 is not blacklisted
< Server: Apache-Coyote/1.1
< Cache-Control: private
< Expires: Thu, 01 Jan 1970 01:00:00 CET
Segmentation fault: 11 (Speicherabzug geschrieben)

Curl crashes with segmentation fault. I am on:
uname -a
FreeBSD hostname2 9.2-STABLE FreeBSD 9.2-STABLE

Core files can be provided on request.

[Daniel Stenberg]

Thanks! Any chance you can (re-)build with debug symbols and get us a back trace with gdb on that crash?

[Michael Osipov]

What exact features shall I enable in the configure script?
While checking Google for the backtrace in GDB, it seems to be straight forward. So, yes: I will provide the files you need.

[Daniel Stenberg]

Do these steps:

$ ./configure --enable-debug (plus whatever extra options you need)
$ make
$ ./src/curl --verbose --negotiate -u : http://hostname:8080/manager/html
core dump

If you get a core dump there, you can analyze it with gdb like:

$ gdb src/curl core
(gdb) where

... where shows the stack trace and is super interesting.

If you don't get a core dump, you can catch the crash without it like this:

$ gdb --args ./src/curl --verbose --negotiate -u : http://hostname:8080/manager/html
(gdb) run
(BOOM)
(gdb) where

[Michael Osipov]

As expected?

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 28c04300 (LWP 101086/curl)]
0x2868da96 in free () from /lib/libc.so.7
(gdb) where
#0  0x2868da96 in free () from /lib/libc.so.7
#1  0x28910032 in krb5_set_default_in_tkt_etypes () from /usr/lib/libkrb5.so.10
#2  0x28983de0 in _gsskrb5_init_sec_context () from /usr/lib/libgssapi_krb5.so.10
#3  0x282c8fcf in gss_init_sec_context () from /usr/lib/libgssapi.so.10
#4  0x280fa0b8 in Curl_gss_init_sec_context (data=0x28c2a004, minor_status=0xbfbfcf10,
    context=0x28c325f0, target_name=0x28c0d640, input_chan_bindings=0x0, input_token=0xbfbfcf04,
    output_token=0xbfbfcefc, ret_flags=0x0) at curl_gssapi.c:54
#5  0x280d9753 in Curl_input_negotiate (conn=0x28d23104, proxy=false, header=0x28c0d62d "")
    at http_negotiate.c:243
#6  0x280a3ced in Curl_http_input_auth (conn=0x28d23104, proxy=false, auth=0x28c0d624 "Negotiate")
    at http.c:756
#7  0x280a9d71 in Curl_http_readwrite_headers (data=0x28c2a004, conn=0x28d23104, nread=0xbfbfd0f0,
    stop_reading=0xbfbfd0ee) at http.c:3455
#8  0x280c54d8 in readwrite_data (data=0x28c2a004, conn=0x28d23104, k=0x28c2a050,
    didwhat=0xbfbfd178, done=0xbfbfd287) at transfer.c:471
#9  0x280c66b2 in Curl_readwrite (conn=0x28d23104, done=0xbfbfd287) at transfer.c:1039
#10 0x280d4847 in multi_runsingle (multi=0x28c33084, now={tv_sec = 347918, tv_usec = 312308},
    data=0x28c2a004) at multi.c:1479
#11 0x280d4f09 in curl_multi_perform (multi_handle=0x28c33084, running_handles=0xbfbfd370)
    at multi.c:1752
#12 0x280c89cd in easy_transfer (multi=0x28c33084) at easy.c:705
#13 0x280c8b6d in easy_perform (data=0x28c2a004, events=false) at easy.c:784
#14 0x280c8bc9 in curl_easy_perform (easy=0x28c2a004) at easy.c:803
#15 0x08057aae in operate (config=0xbfbfd7dc, argc=6, argv=0xbfbfda68) at tool_operate.c:1491
#16 0x08052684 in main (argc=6, argv=0xbfbfda68) at tool_main.c:103

[Daniel Stenberg]

The stack trace is fine, but the problem is not expected to me. The crash is clearly within libkrb5.so.10 but it isn't so clear why or what input libcurl passes in that causes this!

Did this work in a previous version? Can we bisect to an offending change?

[Michael Osipov]

Daniel, I have tried:

7.34.0
  33
  30
  26

They all crash. I have the feeling that it did not work at all. I do know that this is not related to the Heimdal setup because I am co-testing libserf's serf_get and it works as expected.

[Daniel Stenberg]

Could just as well be the GSSAPI lib that causes this. Closing for someone to research at some point in time.

[Michael Osipov]

It's not because I use libserf on the same machine with GSS-API and it works flawlessly.

[Michael Osipov]

Hi Daniel, I do have an update on the issue. It turned out that this is NOT a bug in curl but the base version in FreeBSD, Heimdal 1.1.0 is broken. The very same error has been observed in serf by me recently. This should apply to curl too. One would need to check in the configure script for the Heimdal version. See reference for serf: https://groups.google.com/forum/#!topic/serf-dev/6J3StLWgGIo

[Daniel Stenberg]

Sorry, but what would configure do if it finds heimdal? It seems like a user choice to use that, besides how can configure know if it is a broken version or not?

[Michael Osipov]

If it finds Heimdal, It would check for the version, of course I cannot say when the issue was fixed but 1.1.0 is base on FreeBSD and is broken. So it would be a simple version match with krb5-config --version.

[Michael Osipov]

FYI, I have just compiled curl from the ports tree against MIT Kerberos and it perfectly works.