On Mon, Apr 01, 2002 at 01:30:31PM -0500, Brad Barfield wrote:
> OpenSSL version: 0.9.6c
> OS: Linux 2.4.7-10
> EGCS-2.91.66
>
> I am seeing a crash in my SSL client application where the ssl->s3
> member is NULL..... from my limited understanding of the code, this
> should never happen at the point that I'm seeing it. Below is the gdb
> output from two different crashes:
>
> =======
> crash #1:
> =======
> (gdb) where
> #0 0x08062e09 in ssl3_get_message (s=0x836d650, st1=4384, stn=4385,
> mt=2,
> max=300, ok=0xbffff358) at s3_both.c:344
> #1 0x0805aa53 in ssl3_get_server_hello (s=0x836d650) at s3_clnt.c:549
> #2 0x08059efb in ssl3_connect (s=0x836d650) at s3_clnt.c:200
> #3 0x08067bfb in SSL_connect (s=0x836d650) at ssl_lib.c:720
> #4 0x0804fd56 in ssl_write (i=46) at ssl.c:758
> #5 0x0804d126 in main_loop () at main.c:624
> #6 0x0804e647 in main (argc=11, argv=0xbffff9a4) at main.c:1273
> #7 0x40068507 in __libc_start_main (main=0x804dc08 <main>, argc=11,
> ubp_av=0xbffff9a4, init=0x804b3cc <_init>, fini=0x80e3700 <_fini>,
> rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffff99c)
> at ../sysdeps/generic/libc-start.c:129
>
> (gdb) p s->s3
> $1 = (struct ssl3_state_st *) 0x0
I had a look into the SSL code and I could not find a reason why
s->s3 should become NULL. It is initialized in SSL_new() and destroyed
in SSL_free(). The only additional idea I have would be that there
may be an overflow somewhere that is overwriting part of "SSL *s", so
that s->s3 becomes invalid.
If this problem would be reproduced easily, I would recommend running
with efence enabled, but this is out of options for a long running process,
as it manages to consume large amounts of system resources.
You may consider quering s->3 for being non-NULL before calling
SSL_connect(). If it is NULL, the bug appeared.
> =======
> crash #2:
> =======
> (gdb) where
> #0 0x08062e09 in ssl3_get_finished (s=0x836d650, a=4384, b=4385)
> at s3_both.c:220
> #1 0x0805aa53 in ssl3_connect (s=0x836d650) at s3_clnt.c:418
> #2 0x08059efb in ssl3_connect (s=0x836d650) at s3_clnt.c:114
> #3 0x08067bfb in SSL_pending (s=0x836d650) at ssl_lib.c:596
> #4 0x0804fd56 in ssl_read (i=46) at ssl.c:738
> #5 0x0804d126 in main_loop () at main.c:628
> #6 0x0804e647 in main (argc=11, argv=0xbffff9a4) at main.c:1278
>
> (gdb) p s->s3
> $1 = (struct ssl3_state_st *) 0x0
Here it is even more critical, as it means that s->s3 must have changed
between operations.
> handshake_func = 0x80599f0 <do_ssl_write+608>, server = 0, new_session
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ??
>From the backtrace it also seems, that you are either using implicit
negotiation (by calling SSL_pending()), or that a renegotiation is
taking place. Maybe this can give additional hints for tracking the
problem back.
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
BTU Cottbus, Allgemeine Elektrotechnik
Universitaetsplatz 3-4, D-03044 Cottbus
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
