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"
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)
Hi, any news on this leak. Could you reproduce the issue? Many thanks for your answer.
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; } ...
This makes sense for me.
Fixed in r1874577.
For the records, it has been backported in the 2.4.x branch in r1875552. This is part of 2.4.43.