Can anyone comment on this?

--Cliff

---------- Forwarded message ----------
Date: Thu, 09 Jan 2003 13:48:59 +0100
From: Bernd Steinert <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: [PATCH] A bug in table adjust function that causes a core dump

On Thursday, 5 December 2002, Cliff Wooley replied:

 > On Thu, 5 Dec 2002, Bernd Steinert wrote:
 >
 > > on November 11 Kirill Shirkov reported a bug in the table_adjust function
 > > that causes core dumps. He described how the core dumps can be reproduced.
 > > Some colleague of mine confirmed this behaviour.
 >
 > I must have missed the patch... can someone repost it for me (and CC: me
 > and Ralf on it), and put [PATCH] at the beginning of the subject line of
 > the message.

Thanks a lot Cliff for the immediatereply. (unfortunaltely I missed it
before going
on holidays.)

Here is what Kirill Shirkov wrote on Friday, November 11, 2002 --- his fix
is at the end:

 > Hi folks,
 >
 > I have found a bug in table_adjust function, and I haven't seen any
reports about
 > this error in the mailing list. Also, this error is not fixed in the
current version
 > of mod_ssl (2.8.12).
 >
 > THE BUG
 > -------------
 >
 > ssl_util_table.c file, line 1755:
 >
 >     buckets = (table_entry_t **) table_p->ta_calloc(buck_n,
sizeof(table_entry_t *));
 >     if (table_p->ta_buckets == NULL)
 >         return TABLE_ERROR_ALLOC;
 >
 > buckets variable is not checked here and this causes a coredump when the
table size
 > is big and there is no memory for reallocating the buckets. Below is a
stack dump
 > from Solaris 8 running Apache 1.3.26 + mod_ssl 2.8.10 + OpenSSL 0.9.6g:
 >
 > ...
 >  --- called from signal handler with signal 11 (SIGSEGV) ---
 > 00089b60 table_adjust (0, fe0a09cc, fe09ea84, 0, 3e9, fe08cdd8) + d0
 > 00081cac ssl_scache_shmht_expire (1, 20, fe0e436c, 4, 31, fe08e438) + 130
 > 00081a24 ssl_scache_shmht_store (94, 18aef0, 20, bb8200, bb81b8, 1ad4e0)
+ 11c
 > 0007b7e0 ssl_callback_NewSessionCacheEntry (bb8200, 3dc42bfb, 7b784,
1ad4e0, bb81b8, ba65e0) + 5c
 > fe64c584 ssl_update_cache (a1c458, 2, 21c1, 1ad4e0, 1, a1c458) + a8
 > fe63ef14 ssl3_accept (a1c458, 2100, 21c0, 3004, 90, 0) + 8c8
 > fe64d520 SSL_accept (a1c458, fe63e64c, 1, ba1088, 10, ba109a) + 24
 > fe648d94 ssl23_get_client_hello (2a, 70, 2, ffbef100, 1, a1c458) + 7cc
 > fe648528 ssl23_accept (a1c458, fe648388, 1a1f70, 0, 6f757400, 6f757400)
+ 1a0
 > fe64d520 SSL_accept (a1c458, 79d30, 12c, 0, 16fab0, 17cee0) + 24
 > 00079730 ssl_hook_NewConnection (908cc0, 178000, 1781d0, ffbef2cc,
16fa34, 806478) + 2b4
 > 0004c4a0 new_connection (163b1c, 45415049, 908cc0, ffbef344, ffbef344,
3) + 114
 > 0004d470 child_main (173400, 173400, 173400, ff36b228, ff365958,
ff35efb8) + 634
 > ...
 >
 > HOW TO REPRODUCE
 > ----------------------------------
 >
 > I was able to reproduce the error in the following way:
 >
 > 1. Set SSLSessionCacheTimeout to 20 minutes
 > 2. Set SSLSessionCache size to 1024000 (or a value that is close to your
EAPI_MM_CORE_MAXSIZE).
 > 3. Set ExtendedStatus to On
 > 4. Start the server and run a script like the following one:
 >
 > #!/usr/local/bin/bash
 >
 > i=0
 > while expr $i \< 400 >/dev/null; do
 >     echo $i
 >     i=`expr $i + 1`
 >
 >     for j in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15; do
 >         curl -I https://your.host/ &
 >     done
 >     sleep 1
 > done
 >
 > BTW, you may interrupt the script when the "current sessions" parameter
at the bottom
 > of the server status page (https://your.host/server-status) have stopped
growing.
 >
 > 5. Wait 25 minutes from the time you have started the script and reload
the server
 > status page or access the server over SSL. Most likely you will see a
core dump.
 >
 > THE FIX
 > ------------
 >
 > If we change the if statement like this:..
 >
 >     if (table_p->ta_buckets == NULL || buckets == NULL)
 >         return TABLE_ERROR_ALLOC;
 >
 > ...the server doesn't dump core in the test.
 >
 > Another solution to this problem is to decrease shared memory size in
the config file.
 >
 > Best regards,
 > Kirill Shirokov,
 > St. Petersburg, Russia.


---
Dr. Bernd Steinert
kippdata GmbH           Tel.: 0228 - 9 85 49 0
Bornheimer Str. 33a             Fax: 0228 - 9 85 49 50
D-53111 Bonn                    eMail: [EMAIL PROTECTED]


Reply via email to