You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@codematters.co.uk> on 2007/09/11 18:54:14 UTC
svnserve crash with SASL misconfiguration
While setting up my machine to run the regression tests with SASL I
discovered that it is possible to get svnserve to crash. If I mess up
the mech_list:CRAM-MD5 configuration, leave it out or misspell it say,
then the server crashes when the client attempts to authenticate.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1082132832 (LWP 6021)]
0x00002b1d86623b4c in sasl_write_cb (baton=0x538848,
buffer=0x52c118 "( success ( ) ) nNwYXV0aD04MzRlNWVmNDhkMWQyOTQzNjc0ZDY2ZmQ2ODA2NmQ2MA==\n ) ) NnM9IixyZWFs\nbT0ic3ZudGVzdCIscW9wPSJhdXRoLGF1dGgtaW50LGF1dGgtY29uZiIsY2lwaGVyPSJyYzQtNDAs\ncmM0LTU2LHJjNCxkZXMsM2RlcyIsbWF4Y"...,
len=0x407ffa80) at ../svn/subversion/libsvn_ra_svn/cyrus_auth.c:585
585 sasl_baton->write_len -= tmplen;
(gdb) p sasl_baton
$1 = (sasl_baton_t *) 0x0
(gdb) bt 3
#0 0x00002b1d86623b4c in sasl_write_cb (baton=0x538848,
buffer=0x52c118 "( success ( ) ) nNwYXV0aD04MzRlNWVmNDhkMWQyOTQzNjc0ZDY2ZmQ2ODA2NmQ2MA==\n ) ) NnM9IixyZWFs\nbT0ic3ZudGVzdCIscW9wPSJhdXRoLGF1dGgtaW50LGF1dGgtY29uZiIsY2lwaGVyPSJyYzQtNDAs\ncmM0LTU2LHJjNCxkZXMsM2RlcyIsbWF4Y"...,
len=0x407ffa80) at ../svn/subversion/libsvn_ra_svn/cyrus_auth.c:585
#1 0x00002b1d864f66e1 in svn_stream_write (stream=0x5388a0,
data=0x52c118 "( success ( ) ) nNwYXV0aD04MzRlNWVmNDhkMWQyOTQzNjc0ZDY2ZmQ2ODA2NmQ2MA==\n ) ) NnM9IixyZWFs\nbT0ic3ZudGVzdCIscW9wPSJhdXRoLGF1dGgtaW50LGF1dGgtY29uZiIsY2lwaGVyPSJyYzQtNDAs\ncmM0LTU2LHJjNCxkZXMsM2RlcyIsbWF4Y"...,
len=0x407ffa80) at ../svn/subversion/libsvn_subr/stream.c:105
#2 0x00002b1d8662b794 in svn_ra_svn__stream_write (stream=0x538880,
data=0x52c118 "( success ( ) ) nNwYXV0aD04MzRlNWVmNDhkMWQyOTQzNjc0ZDY2ZmQ2ODA2NmQ2MA==\n ) ) NnM9IixyZWFs\nbT0ic3ZudGVzdCIscW9wPSJhdXRoLGF1dGgtaW50LGF1dGgtY29uZiIsY2lwaGVyPSJyYzQtNDAs\ncmM0LTU2LHJjNCxkZXMsM2RlcyIsbWF4Y"...,
len=0x407ffa80) at ../svn/subversion/libsvn_ra_svn/streams.c:230
(More stack frames follow...)
(gdb)
Is this a known problem?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnserve crash with SASL misconfiguration
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@codematters.co.uk> writes:
> If I use a 1.4 client not only does the SIGSEGV go away but the
> authentication succeeds. That surprises me, I thought I would need to
> use a 1.5 client to authenticate against a SASL server?
I see notes/sasl.txt explains that a 1.4 client will work with a SASL
server using CRAM-MD5.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnserve crash with SASL misconfiguration
Posted by Philip Martin <ph...@codematters.co.uk>.
Vlad Georgescu <vg...@gmail.com> writes:
> Philip Martin wrote:
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 1082132832 (LWP 6021)]
>> 0x00002b1d86623b4c in sasl_write_cb (baton=0x538848,
>> buffer=0x52c118 "( success ( ) ) nNwYXV0aD04MzRlNWVmNDhkMWQyOTQzNjc0ZDY2ZmQ2ODA2NmQ2MA==\n ) ) NnM9IixyZWFs\nbT0ic3ZudGVzdCIscW9wPSJhdXRoLGF1dGgtaW50LGF1dGgtY29uZiIsY2lwaGVyPSJyYzQtNDAs\ncmM0LTU2LHJjNCxkZXMsM2RlcyIsbWF4Y"...,
>> len=0x407ffa80) at ../svn/subversion/libsvn_ra_svn/cyrus_auth.c:585
>> 585 sasl_baton->write_len -= tmplen;
>> (gdb) p sasl_baton
>> $1 = (sasl_baton_t *) 0x0
>
> It's strange that sasl_baton is NULL here. sasl_baton is the same as
> sasl_write_cb's baton argument, which is not NULL. Can you figure out
> when sasl_baton becomes NULL?
When sasl_write_cb calls svn_ra_svn__stream_write:
Breakpoint 1, sasl_write_cb (baton=0x538888,
buffer=0x52c158 "( success ( ) ) nNwYXV0aD1lZjg4ZDNmYjU2MTg5OGQwZTEzMGJlZTdjZGQ4NWQyOQ==\n ) ) eXM9IixyZWFs\nbT0ic3ZudGVzdCIscW9wPSJhdXRoLGF1dGgtaW50LGF1dGgtY29uZiIsY2lwaGVyPSJyYzQtNDAs\ncmM0LTU2LHJjNCxkZXMsM2RlcyIsbWF4Y"...,
len=0x407ffa80) at ../src/subversion/libsvn_ra_svn/cyrus_auth.c:555
555 sasl_baton_t *sasl_baton = baton;
(gdb) n
558 if (! sasl_baton->write_buf || sasl_baton->write_len == 0)
(gdb)
561 *len = (*len > sasl_baton->maxsize) ? sasl_baton->maxsize : *len;
(gdb)
562 result = sasl_encode(sasl_baton->ctx, buffer, *len,
(gdb)
566 if (result != SASL_OK)
(gdb)
573 unsigned int tmplen = sasl_baton->write_len;
(gdb)
574 SVN_ERR(svn_ra_svn__stream_write(sasl_baton->stream,
(gdb) p sasl_baton
$1 = (sasl_baton_t *) 0x538888
(gdb) p tmplen
$2 = 36
(gdb) n
577 if (tmplen == 0)
(gdb) p sasl_baton
$3 = (sasl_baton_t *) 0x0
(gdb)
I've just noticed that the server's call to svn_ra_svn__stream_write
causes the client to SIGSEGV as well:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47822049507328 (LWP 2354)]
0x00002b7e6d0f81a0 in apr_socket_timeout_set () from /usr/lib/libapr-1.so.0
(gdb) bt 6
#0 0x00002b7e6d0f81a0 in apr_socket_timeout_set () from /usr/lib/libapr-1.so.0
#1 0x00002b7e6de134c7 in sock_read_cb (baton=0x553dd0, buffer=0x551cbc "",
len=0x7fff3e305114) at ../src/subversion/libsvn_ra_svn/streams.c:149
#2 0x00002b7e6ce9590a in svn_stream_read (stream=0x553e00,
buffer=0x551cbc "", len=0x7fff3e305114)
at ../src/subversion/libsvn_subr/stream.c:97
#3 0x00002b7e6de137be in svn_ra_svn__stream_read (stream=0x553de0,
data=0x551cbc "", len=0x7fff3e305114)
at ../src/subversion/libsvn_ra_svn/streams.c:237
#4 0x00002b7e6de0b8af in sasl_read_cb (baton=0x54a950, buffer=0x551cbc "",
len=0x7fff3e305228) at ../src/subversion/libsvn_ra_svn/cyrus_auth.c:516
#5 0x00002b7e6ce9590a in svn_stream_read (stream=0x54a9a8,
buffer=0x551cbc "", len=0x7fff3e305228)
at ../src/subversion/libsvn_subr/stream.c:97
(More stack frames follow...)
(gdb) up
#1 0x00002b7e6de134c7 in sock_read_cb (baton=0x553dd0, buffer=0x551cbc "",
len=0x7fff3e305114) at ../src/subversion/libsvn_ra_svn/streams.c:149
149 apr_socket_timeout_set(b->sock, interval);
(gdb) p b->sock
$1 = (apr_socket_t *) 0x0
(gdb)
If I use a 1.4 client not only does the SIGSEGV go away but the
authentication succeeds. That surprises me, I thought I would need to
use a 1.5 client to authenticate against a SASL server?
Running the server under valgrind I get:
==2502== Syscall param write(buf) points to uninitialised byte(s)
==2502== at 0x565212F: (within /usr/lib/debug/libpthread-2.3.6.so)
==2502== by 0x51F98A4: apr_socket_send (in /usr/lib/libapr-1.so.0.2.7)
==2502== by 0x4FBC595: sock_write_cb (streams.c:164)
==2502== by 0x4E88964: svn_stream_write (stream.c:105)
==2502== by 0x4FBC793: svn_ra_svn__stream_write (streams.c:230)
==2502== by 0x4FB4B16: sasl_write_cb (cyrus_auth.c:574)
==2502== by 0x4E88964: svn_stream_write (stream.c:105)
==2502== by 0x4FBC793: svn_ra_svn__stream_write (streams.c:230)
==2502== by 0x4FB8AF2: writebuf_output (marshal.c:152)
==2502== by 0x4FB8C7B: writebuf_flush (marshal.c:186)
==2502== by 0x4FB9125: readbuf_fill (marshal.c:274)
==2502== by 0x4FB91E7: readbuf_getchar (marshal.c:286)
==2502== Address 0x78619E4 is 36 bytes inside a block of size 44 alloc'd
==2502== at 0x4A1B858: malloc (vg_replace_malloc.c:149)
==2502== by 0x5871704: _plug_buf_alloc (in /usr/lib/libsasl2.so.2.0.22)
==2502== by 0x7CCE861: (within /usr/lib/sasl2/libdigestmd5.so.2.0.22)
==2502== by 0x586A905: (within /usr/lib/libsasl2.so.2.0.22)
==2502== by 0x586ADFF: sasl_encodev (in /usr/lib/libsasl2.so.2.0.22)
==2502== by 0x586AFAD: sasl_encode (in /usr/lib/libsasl2.so.2.0.22)
==2502== by 0x4FB4AB2: sasl_write_cb (cyrus_auth.c:562)
==2502== by 0x4E88964: svn_stream_write (stream.c:105)
==2502== by 0x4FBC793: svn_ra_svn__stream_write (streams.c:230)
==2502== by 0x4FB8AF2: writebuf_output (marshal.c:152)
==2502== by 0x4FB8C7B: writebuf_flush (marshal.c:186)
==2502== by 0x4FB9125: readbuf_fill (marshal.c:274)
==2502==
==2502== Invalid read of size 4
==2502== at 0x4FB4B4C: sasl_write_cb (cyrus_auth.c:585)
==2502== by 0x4E88964: svn_stream_write (stream.c:105)
==2502== by 0x4FBC793: svn_ra_svn__stream_write (streams.c:230)
==2502== by 0x4FB8AF2: writebuf_output (marshal.c:152)
==2502== by 0x4FB8C7B: writebuf_flush (marshal.c:186)
==2502== by 0x4FB9125: readbuf_fill (marshal.c:274)
==2502== by 0x4FB91E7: readbuf_getchar (marshal.c:286)
==2502== by 0x4FB9254: readbuf_getchar_skip_whitespace (marshal.c:296)
==2502== by 0x4FBA5B3: svn_ra_svn_read_item (marshal.c:652)
==2502== by 0x4FBB3C5: svn_ra_svn_read_tuple (marshal.c:782)
==2502== by 0x4FB7E68: svn_ra_svn_drive_editor2 (editorp.c:880)
==2502== by 0x4FB8195: svn_ra_svn_drive_editor (editorp.c:933)
==2502== Address 0x30 is not stack'd, malloc'd or (recently) free'd
and for the client:
==2503== Syscall param socketcall.sendto(msg) points to uninitialised byte(s)
==2503== at 0x5BA0365: __sendto_nocancel (in /usr/lib/debug/libc-2.3.6.so)
==2503== by 0x5BBE9B9: __check_pf (in /usr/lib/debug/libc-2.3.6.so)
==2503== by 0x5B8B01C: getaddrinfo (in /usr/lib/debug/libc-2.3.6.so)
==2503== by 0x534E56D: (within /usr/lib/libapr-1.so.0.2.7)
==2503== by 0x6056440: make_connection (client.c:131)
==2503== by 0x60575C2: open_session (client.c:528)
==2503== by 0x6057AB3: ra_svn_open (client.c:632)
==2503== by 0x4DB5BFA: svn_ra_open2 (ra_loader.c:462)
==2503== by 0x4B550B6: svn_client__open_ra_session_internal (ra.c:299)
==2503== by 0x4B2AD32: mkdir_urls (add.c:729)
==2503== by 0x4B2B06B: svn_client_mkdir3 (add.c:811)
==2503== by 0x410838: svn_cl__mkdir (mkdir-cmd.c:77)
==2503== Address 0x7FEFFFD31 is on thread 1's stack
==2503==
==2503== Syscall param read(buf) points to unaddressable byte(s)
==2503== at 0x57A8182: __read_nocancel (in /usr/lib/debug/libpthread-2.3.6.so)
==2503== by 0x534F7C4: apr_socket_recv (in /usr/lib/libapr-1.so.0.2.7)
==2503== by 0x60664B3: sock_read_cb (streams.c:148)
==2503== by 0x50F9909: svn_stream_read (stream.c:97)
==2503== by 0x60667BD: svn_ra_svn__stream_read (streams.c:237)
==2503== by 0x605E8AE: sasl_read_cb (cyrus_auth.c:516)
==2503== by 0x50F9909: svn_stream_read (stream.c:97)
==2503== by 0x60667BD: svn_ra_svn__stream_read (streams.c:237)
==2503== by 0x6062FE0: readbuf_input (marshal.c:250)
==2503== by 0x606315B: readbuf_fill (marshal.c:276)
==2503== by 0x60631E7: readbuf_getchar (marshal.c:286)
==2503== by 0x6063254: readbuf_getchar_skip_whitespace (marshal.c:296)
==2503== Address 0x86CBE40 is 0 bytes after a block of size 12,288 alloc'd
==2503== at 0x4A1B858: malloc (vg_replace_malloc.c:149)
==2503== by 0x534C14C: apr_palloc (in /usr/lib/libapr-1.so.0.2.7)
==2503== by 0x50FF97B: my__realloc (svn_string.c:46)
==2503== by 0x5100279: svn_stringbuf_ensure (svn_string.c:359)
==2503== by 0x51002BA: svn_stringbuf_appendbytes (svn_string.c:379)
==2503== by 0x50FB11E: write_handler_string (stream.c:848)
==2503== by 0x50F9964: svn_stream_write (stream.c:105)
==2503== by 0x50FC0A8: translate_write (subst.c:473)
==2503== by 0x50FD1B2: translate_chunk (subst.c:1061)
==2503== by 0x50FD574: translated_stream_read (subst.c:1173)
==2503== by 0x50F9909: svn_stream_read (stream.c:97)
==2503== by 0x50E4A8E: parser_getc (config_file.c:85)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnserve crash with SASL misconfiguration
Posted by Vlad Georgescu <vg...@gmail.com>.
Hi Philip,
Philip Martin wrote:
> While setting up my machine to run the regression tests with SASL I
> discovered that it is possible to get svnserve to crash. If I mess up
> the mech_list:CRAM-MD5 configuration, leave it out or misspell it say,
> then the server crashes when the client attempts to authenticate.
When SASL can't find a valid mech_list line, it will load _all_
available authentication plugins from a known location (/usr/lib/sasl2).
Looking at the stack trace, it ends up using a plugin that supports
encryption (sasl_write_cb is the callback that encrypts data before
sending it over the wire). However, I'm not able to reproduce the crash.
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1082132832 (LWP 6021)]
> 0x00002b1d86623b4c in sasl_write_cb (baton=0x538848,
> buffer=0x52c118 "( success ( ) ) nNwYXV0aD04MzRlNWVmNDhkMWQyOTQzNjc0ZDY2ZmQ2ODA2NmQ2MA==\n ) ) NnM9IixyZWFs\nbT0ic3ZudGVzdCIscW9wPSJhdXRoLGF1dGgtaW50LGF1dGgtY29uZiIsY2lwaGVyPSJyYzQtNDAs\ncmM0LTU2LHJjNCxkZXMsM2RlcyIsbWF4Y"...,
> len=0x407ffa80) at ../svn/subversion/libsvn_ra_svn/cyrus_auth.c:585
> 585 sasl_baton->write_len -= tmplen;
> (gdb) p sasl_baton
> $1 = (sasl_baton_t *) 0x0
It's strange that sasl_baton is NULL here. sasl_baton is the same as
sasl_write_cb's baton argument, which is not NULL. Can you figure out
when sasl_baton becomes NULL?
> (gdb) bt 3
> #0 0x00002b1d86623b4c in sasl_write_cb (baton=0x538848,
> buffer=0x52c118 "( success ( ) ) nNwYXV0aD04MzRlNWVmNDhkMWQyOTQzNjc0ZDY2ZmQ2ODA2NmQ2MA==\n ) ) NnM9IixyZWFs\nbT0ic3ZudGVzdCIscW9wPSJhdXRoLGF1dGgtaW50LGF1dGgtY29uZiIsY2lwaGVyPSJyYzQtNDAs\ncmM0LTU2LHJjNCxkZXMsM2RlcyIsbWF4Y"...,
> len=0x407ffa80) at ../svn/subversion/libsvn_ra_svn/cyrus_auth.c:585
> #1 0x00002b1d864f66e1 in svn_stream_write (stream=0x5388a0,
> data=0x52c118 "( success ( ) ) nNwYXV0aD04MzRlNWVmNDhkMWQyOTQzNjc0ZDY2ZmQ2ODA2NmQ2MA==\n ) ) NnM9IixyZWFs\nbT0ic3ZudGVzdCIscW9wPSJhdXRoLGF1dGgtaW50LGF1dGgtY29uZiIsY2lwaGVyPSJyYzQtNDAs\ncmM0LTU2LHJjNCxkZXMsM2RlcyIsbWF4Y"...,
> len=0x407ffa80) at ../svn/subversion/libsvn_subr/stream.c:105
> #2 0x00002b1d8662b794 in svn_ra_svn__stream_write (stream=0x538880,
> data=0x52c118 "( success ( ) ) nNwYXV0aD04MzRlNWVmNDhkMWQyOTQzNjc0ZDY2ZmQ2ODA2NmQ2MA==\n ) ) NnM9IixyZWFs\nbT0ic3ZudGVzdCIscW9wPSJhdXRoLGF1dGgtaW50LGF1dGgtY29uZiIsY2lwaGVyPSJyYzQtNDAs\ncmM0LTU2LHJjNCxkZXMsM2RlcyIsbWF4Y"...,
> len=0x407ffa80) at ../svn/subversion/libsvn_ra_svn/streams.c:230
> (More stack frames follow...)
> (gdb)
>
--
Vlad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org