A bug in table_adjust function that causes a core dump
Hi, 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. Shirkov also described a bug fix. Up to now (December 5) there are no changes in the file ssl_util_table.c in the mod_ssl CVS repository. So, I would like to aks: 1. Is Shirkovs code change going to be integrated in the offical code? Or is there some other fix for this bug that will be integrarted? 2. When can some fix be expected in CVS? 3. When can it be expected to be seen in some offical release? Thanks a lot for any answer! Bernd Steinert --- 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] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: A bug in table_adjust function that causes a core dump
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. 1. Is Shirkovs code change going to be integrated in the offical code? Sure... I just need a copy of it. 2. When can some fix be expected in CVS? 3. When can it be expected to be seen in some offical release? I can handle the commit to the 2.0.x series... but it's up to Ralf to have it incorporated into the next release for 1.3.x. Thanks, Cliff __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: A bug in table_adjust function that causes a core dump
Hi, I would be very interested if there is any progress concerning this bug (table_adjust in ssl_util_table.c). Are there plans to include the fix in the code? Has the bug been reproduced? Also there was another Bug found some weeks ago concerning a memory leak when using client certificates. The bugfix obviously is now in the CVS tree. Does anyone know, when this code will be released (most liekely as 2.8.13)? Any answers would be very helpful, because we care about a site which is very soon starting to heavily use client certificates and also we observed a lot of apache processes core dumping on friday (not related to the certificates). Best regards, Rainer Jung kippdata informationstechnologie GmbH Bornheimer Straße 33a D-53111 Bonn Germany Tel.: +49/228/98549-0 Fax: +49/228/98549-50 email: [EMAIL PROTECTED] At 16:26 08.11.02, you wrote: 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. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
A bug in table_adjust function that causes a core dump
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. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
