Bug 63077 - Memory leak if SSLUseStapling is on
Summary: Memory leak if SSLUseStapling is on
Status: RESOLVED FIXED
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl (show other bugs)
Version: 2.4.37
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: PatchAvailable
Depends on:
Blocks:
 
Reported: 2019-01-15 09:28 UTC by paolo
Modified: 2020-06-01 07:05 UTC (History)
1 user (show)



Attachments
output of valgrind. Look for line 9115 (695.86 KB, text/x-log)
2019-01-15 09:28 UTC, paolo
Details
Proposed patch (679 bytes, patch)
2019-03-27 10:18 UTC, paolo
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description paolo 2019-01-15 09:28:37 UTC
Created attachment 36376 [details]
output of valgrind. Look for line 9115

Hi,

valgrind reports a leak when enabling SSLUseStapling. I did install httpd and set those attributes:

SSLUseStapling   on
SSLStaplingCache shmcb:/tmp/stapling_cache(16384)
SSLStaplingStandardCacheTimeout 1



after several requests like:
printf "" | openssl s_client -connect localhost:443 -CAfile /var/opt/OpenSSLCA/CA/ca/cert/ca.pem -status

my host did run out of memory.


With valgrind I can see this (after a single request: openssl s_client -connect localhost:443 -CAfile /var/opt/OpenSSLCA/CA/ca/cert/ca.pem -status)

Without stapling:
==25377== LEAK SUMMARY:
==25377== definitely lost: 0 bytes in 0 blocks
==25377== indirectly lost: 0 bytes in 0 blocks

With stapling:
==24345== LEAK SUMMARY:
==24345== definitely lost: 16 bytes in 1 blocks
==24345== indirectly lost: 1,844 bytes in 5 blocks


So there seems to be a leak somewhere in mod_ssl. 

Find attached the valgrind output.


Thank you for investigating this leak.

Best Regards
	Paolo Ganci
	

paolo@localhost:~> /var/opt/httpd/bin/httpd -V
Server version: Apache/2.4.37 (Unix)
Server built:   Jan 14 2019 12:42:25
Server's Module Magic Number: 20120211:83
Server loaded:  APR 1.6.5, APR-UTIL 1.6.1
Compiled using: APR 1.6.5, APR-UTIL 1.6.1
Architecture:   64-bit
Server MPM:     worker
  threaded:     yes (fixed thread count)
    forked:     yes (variable process count)
Server compiled with....
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=256
 -D HTTPD_ROOT="/var/opt/httpd"
 -D SUEXEC_BIN="/var/opt/httpd/bin/suexec"
 -D DEFAULT_PIDLOG="logs/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"
Comment 1 paolo 2019-01-15 09:30:02 UTC
Here the stacktrace of the leak:

==10180== 3,720 (32 direct, 3,688 indirect) bytes in 2 blocks are definitely lost in loss record 207 of 247
==10180==    at 0x4C29BC3: malloc (vg_replace_malloc.c:299)
==10180==    by 0x525344D: CRYPTO_zalloc (in /var/opt/openssl/lib/libcrypto.so.1.1)
==10180==    by 0x516D9F3: ASN1_item_ex_new (in /var/opt/openssl/lib/libcrypto.so.1.1)
==10180==    by 0x516BCF6: ASN1_item_ex_d2i (in /var/opt/openssl/lib/libcrypto.so.1.1)
==10180==    by 0x516BDC3: ASN1_item_d2i (in /var/opt/openssl/lib/libcrypto.so.1.1)
==10180==    by 0x5154D9C: ASN1_d2i_bio (in /var/opt/openssl/lib/libcrypto.so.1.1)
==10180==    by 0x48F780: read_response (ssl_util_ocsp.c:295)
==10180==    by 0x48F780: modssl_dispatch_ocsp_request (ssl_util_ocsp.c:334)
==10180==    by 0x48C7C0: stapling_renew_response (ssl_util_stapling.c:504)
==10180==    by 0x48C7C0: stapling_cb (ssl_util_stapling.c:802)
==10180==    by 0x4E95AFF: tls_post_process_client_hello (in /var/opt/openssl/lib/libssl.so.1.1)
==10180==    by 0x4E851A5: state_machine (in /var/opt/openssl/lib/libssl.so.1.1)
==10180==    by 0x4E70757: SSL_do_handshake (in /var/opt/openssl/lib/libssl.so.1.1)
==10180==    by 0x47EE8D: ssl_io_filter_handshake (ssl_engine_io.c:1339)
Comment 2 paolo 2019-03-04 10:20:35 UTC
Hi,

any news on this leak. Could you reproduce the issue?

Many thanks for your answer.
Comment 3 paolo 2019-03-27 10:18:34 UTC
Created attachment 36498 [details]
Proposed patch

Hi,

I could fix this leak by adding those lines in ssl_util_stapling.c

static int stapling_cb(SSL *ssl, void *arg)
...
    if (rsp && ((ok == TRUE) || (mctx->stapling_return_errors == TRUE))) {
        ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s, APLOGNO(01956)
                     "stapling_cb: setting response");
        if (!stapling_set_response(ssl, rsp))
 +    {
 +        OCSP_RESPONSE_free(rsp);
            return SSL_TLSEXT_ERR_ALERT_FATAL;
 +     }
 +   OCSP_RESPONSE_free(rsp);
        return SSL_TLSEXT_ERR_OK;
    }
...
Comment 4 Giovanni Bechis 2019-12-24 10:21:24 UTC
This makes sense for me.
Comment 5 Giovanni Bechis 2020-03-22 12:03:31 UTC
Fixed in r1874577.
Comment 6 Christophe JAILLET 2020-06-01 07:05:26 UTC
For the records, it has been backported in the 2.4.x branch in r1875552.
This is part of 2.4.43.