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 modssl-users@modssl.org
Automated List Manager majordomo@modssl.org

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: rainer.jung@kippdata.de

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 modssl-users@modssl.org
>Automated List Manager majordomo@modssl.org

____________________________________________________________ __________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List modssl-users@modssl.org
Automated List Manager majordomo@modssl.org