Re: [EXT] RE: Conflict between TLS module and HTTP_CLIENT causing kamailio 5.8.8 to crash

Ihor Olkhovskyi via sr-users <[email protected]> Mon, 1 Jun 2026 16:35:10 +0200
Newsgroups gmane.comp.voip.ser
Message-ID <CAJTkRNuiAf0v0J4GyLJvCvvUbkr+fw9SVuxQ7Tp6g=Dndq49Lg@mail.gmail.com>
Emmanuel,

Have you set tls_threads_mode
<https://www.kamailio.org/wikidocs/cookbooks/5.8.x/core/#tls_threads_mode> ?

Cheers,
Ihor

Le lun. 1 juin 2026 à 15:34, Henning Westerholt via sr-users <
[email protected]> a écrit :

> Yes, the branch 5.8 is also effectively end of life now, so no major
> backports etc.. will be done from the project. Also consider this when
> doing the upgrade.
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> *From:* Emmanuel BUU <[email protected]>
> *Sent:* Montag, 1. Juni 2026 15:12
> *To:* Henning Westerholt <[email protected]>; Kamailio (SER) - Users Mailing
> List <[email protected]>
> *Subject:* Re: [EXT] RE: [SR-Users] Conflict between TLS module and
> HTTP_CLIENT causing kamailio 5.8.8 to crash
>
>
>
> Hi,
>
> Thanks for the suggestion. I looked into the tls_init.c of K 6.1.3 and
> CRYPTO_set_mem_functions() is still used. PR 4640
> <https://github.com/kamailio/kamailio/pull/4640> is not merged into this
> version. So I am a bit skeptical ...
>
> I'll keep the suggestion in mind.
>
> Cheers,
>
> Emmanuel
>
> Le 01/06/2026 à 14:35, Henning Westerholt a écrit :
>
> Hello,
>
>
>
> I would probably just try Kamailio 6.1.3 (from last week) instead of
> trying to backport the mentioned PR to the 5.8 branch. There were AFAIK
> also other changes done related to the TLS module in this release, so it
> might be not that trivial to backport in the end.
>
>
>
> Your jump from 4.7 to a more modern release is large enough anyway, so it
> does not make a big difference to not going to the most recent version. 😉
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> *From:* Emmanuel BUU via sr-users <[email protected]>
> <[email protected]>
> *Sent:* Montag, 1. Juni 2026 13:58
> *To:* [email protected]
> *Cc:* Emmanuel BUU <[email protected]> <[email protected]>
> *Subject:* [SR-Users] Conflict between TLS module and HTTP_CLIENT causing
> kamailio 5.8.8 to crash
>
>
>
> Hi everybody,
>
> We are in the process of migrating from kamailio 4.7 to 5.8. We are
> hitting a reproducible SIGSEGV when the http_client module performs an
> HTTPS request while the tls module is also loaded. After analysis it looks
> like a conflict between the tls module's OpenSSL memory allocator
> override and libcurl sharing the same OpenSSL library. I would like to
> report it and get the developers' opinion
>
> *Environment*
>
> - kamailio 5.8.8 (x86_64/linux), AlmaLinux 9.6, sofware recompiled from
> source.
> - OpenSSL 3.5.1
> - libcurl 7.76.1, OpenSSL backend
> - http_client.so and tls.so are linked against the SAME libcrypto.so.3
> - Multi-process (default forking model), tls used for WSS listeners
>
> *Call scenario*
>
> Call to a registed UA. When the call is being process, the kamailio script
> (kamailio.cfg) uses http_client_query to POST to Amazon SNS (Simple
> Notification Service) to handle push notifications. When the call is being
> process, kamailio crashes when the http_client_query function is called. *This
> is happening for every single call*.
>
> I did make sure that tls.so is loaded BEFORE http_client.so as per the doc.
>
> *Analysis*
>
> Here is the core stack trace:
>
> == Backtrace (trimmed) ==
>
>   #0  ossl_asn1_primitive_free (pval=..., it=0x0, embed=0) at
> crypto/asn1/tasn_fre.c:174
>   #1  ossl_asn1_primitive_free (...) at crypto/asn1/tasn_fre.c:203
>   #2  ossl_asn1_template_free (...) at crypto/asn1/tasn_fre.c:146
>   #3  ossl_asn1_item_embed_free (...) at crypto/asn1/tasn_fre.c:114
>   #4  ASN1_item_free (...) at crypto/asn1/tasn_fre.c:20
>   #5  x509_pubkey_ex_free (...) at crypto/x509/x_pubkey.c:91
>   ...
>   #27 PEM_X509_INFO_read_bio_ex (...) at crypto/pem/pem_info.c:168
>   #28 X509_load_cert_crl_file_ex (...) at crypto/x509/by_file.c:250
>   #31 X509_STORE_load_file_ex (...,
> file="/etc/pki/tls/certs/ca-bundle.crt", ...) at crypto/x509/x509_d2.c:57
>   #32 SSL_CTX_load_verify_file (...,
> CAfile="/etc/pki/tls/certs/ca-bundle.crt") at ssl/ssl_lib.c:5613
>   #33 ossl_connect_step1 (...) at ../../lib/vtls/openssl.c:3043
>   #34 ossl_connect_common (...) at ../../lib/vtls/openssl.c:4045
>   #35 Curl_ssl_connect_nonblocking (...) at ../../lib/vtls/vtls.c:370
>   #37 Curl_http_connect (...) at ../../lib/http.c:1519
>   #40 multi_runsingle (...) at ../../lib/multi.c:1847
>   #41 curl_multi_perform (...) at ../../lib/multi.c:2403
>   #44 curl_easy_perform (data=...) at ../../lib/easy.c:715
>   #45 curL_request_url (..., _url="https://.../notifications/event"
> <https://.../notifications/event>, ...) at functions.c:298
>   #46 http_client_request_c (...) at functions.c:720
>   #48 http_client_query (...) at functions.c:744
>   #50 w_http_query_script (...) at http_client.c:1007
>   #51 w_http_query_post (...) at http_client.c:1024
>   #52 do_action ()
>   ...
>
> *Claude point of view on the issue*
>
> Because http_client uses libcurl, which uses the very same OpenSSL,
> libcurl's
> TLS allocations also go into Kamailio shared memory. OpenSSL 3.x keeps
> process
> -global state (OSSL_LIB_CTX, providers, the OSSL_DECODER method cache,
> algorithm
> fetch caches). When libcurl triggers the ASN.1 decode of the CA bundle,
> OpenSSL
> writes into those global caches - which now live in SHM and are shared by
> every
> worker process - while the pointers referencing them are in each process's
> private (COW) memory. OpenSSL's internal mutexes are process-local, so
> multiple
> workers end up reading/writing the same SHM OpenSSL structures concurrently
> without effective cross-process locking, corrupting the SHM heap. The
> crash then
> surfaces in the ASN.1 decoder (corrupted item, it=NULL).
>
> *Related issues / pull requests :*
>
>    1. https://github.com/kamailio/kamailio/pull/4640 - removal of SHM and
>    pthreads shims in multi-threaded mode
>    2. https://github.com/kamailio/kamailio/issues/2912
>
> My questions:
>
>    1. Should we migrate to 6.1 or backport the PR 4640?
>    2. Could it be caused by the fact that libssh is autoinitializing
>    itself when the .so is loaded ?
>    3. Has someone run into this?
>
> Thanks in advance,
>
> Emmanuel
>
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions --
> [email protected]
> To unsubscribe send an email to [email protected]
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
>


-- 
Best regards,
Ihor (Igor)

__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- [email protected]
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the sender!