https://bugs.openldap.org/show_bug.cgi?id=10330
Issue ID: 10330
Summary: TIMEOUT and NETWORK_TIMEOUT not respected when
receiving bad data during TLS negotiation
Product: OpenLDAP
Version: 2.6.9
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Created attachment 1063
--> https://bugs.openldap.org/attachment.cgi?id=1063&action=edit
Test program
This seems related to bug 8047.
Steps to reproduce:
1. Setup a netcat server on a host: "nc -l -k -p 636".
2. On a different host, attempt to connect to the host running "nc" as if it
were an LDAP server via ldaps: "ldapsearch -o NETWORK_TIMEOUT=5 -o TIMEOUT=5 -H
ldaps://<ip>:636".
3. During the 5 second timeout period, switch back to the netcat server and
transmit a newline by pressing enter.
4. ldapsearch will hang forever until the TCP connection is closed (e.g. by
killing the netcat server).
My expectation would be that ldapsearch would exit after 5 seconds, per the
NETWORK_TIMEOUT and TIMEOUT options.
I'm using the following version of ldapsearch on Fedora 41 (x86-64):
> ldapsearch: @(#) $OpenLDAP: ldapsearch 2.6.9 (Mar 27 2025 00:00:00) $
> openldap
> (LDAP library: OpenLDAP 20609)
This problem is also observable when directly using the OpenLDAP C API. This is
more of an issue, since any application using the API could become unresponsive
if these timeout values aren't respected.
I've attached a short test program which can be used instead of ldapsearch. If
I abort the test program while it is stuck in this state, the traceback looks
like this:
> #0 0x00007f50b7a25811 in __GI___libc_read (fd=3, buf=0x2aaf9ac5, nbytes=3)
> at ../sysdeps/unix/sysv/linux/read.c:26
> #1 0x00007f50b792f8b9 in sb_debug_read (sbiod=0x2aadf390, buf=0x2aaf9ac5,
> len=3)
> at
> /usr/src/debug/openldap-2.6.9-1.fc41.x86_64/openldap-2.6.9/libraries/liblber/sockbuf.c:829
> #2 0x00007f50b7b61156 in tlso_bio_read (b=0x2aadf9c0, buf=0x2aaf9ac5 "",
> len=3)
> at
> /usr/src/debug/openldap-2.6.9-1.fc41.x86_64/openldap-2.6.9/libraries/libldap/tls_o.c:1279
> #3 0x00007f50b7221ea3 in bread_conv (bio=<optimized out>, data=<optimized
> out>, datal=<optimized out>, readbytes=0x7ffd1cf2e3f0)
> at crypto/bio/bio_meth.c:121
> #4 0x00007f50b7226047 in bio_read_intern (b=b@entry=0x2aadf9c0,
> data=0x2aaf9ac5, data@entry=0x555f3588, dlen=3,
> dlen@entry=18446744072487067717,
> readbytes=readbytes@entry=0x7ffd1cf2e3f0) at crypto/bio/bio_lib.c:285
> #5 0x00007f50b72261db in BIO_read (b=0x2aadf9c0, data=0x555f3588,
> dlen=-1222483899) at crypto/bio/bio_lib.c:311
> #6 BIO_read (b=b@entry=0x2aadf9c0, data=data@entry=0x2aaf9ac5,
> dlen=dlen@entry=3) at crypto/bio/bio_lib.c:303
> #7 0x00007f50b783ce03 in tls_default_read_n (rl=0x2aaec1c0, n=5,
> max=<optimized out>, extend=<optimized out>, clearold=<optimized out>,
> readbytes=0x7ffd1cf2e4b8) at ssl/record/methods/tls_common.c:406
> #8 0x00007f50b784151b in tls_get_more_records (rl=0x2aaec1c0) at
> ssl/record/methods/tls_common.c:583
> #9 0x00007f50b783b8ea in tls_read_record (rl=0x2aaec1c0,
> rechandle=0x2aaeb600, rversion=0x2aaeb608, type=0x2aaeb60c "",
> data=0x2aaeb610,
> datalen=0x2aaeb620, epoch=0x0, seq_num=0x0) at
> ssl/record/methods/tls_common.c:1130
> #10 0x00007f50b783969a in ssl3_read_bytes (ssl=<optimized out>, type=22
> '\026', recvd_type=0x7ffd1cf2e684 "", buf=0x2aaee480 "\001", len=4,
> peek=0, readbytes=0x7ffd1cf2e688) at ssl/record/rec_layer_s3.c:689
> #11 0x00007f50b784f5a7 in tls_get_message_header (s=0x2aaea980, mt=<synthetic
> pointer>) at ssl/statem/statem_lib.c:1554
> --Type <RET> for more, q to quit, c to continue without paging--
> #12 read_state_machine (s=0x2aaea980) at ssl/statem/statem.c:625
> #13 state_machine (s=<optimized out>, server=0) at ssl/statem/statem.c:479
> #14 0x00007f50b7b615c3 in tlso_session_connect (ld=<optimized out>,
> sess=0x2aaea980, name_in=<optimized out>)
> at
> /usr/src/debug/openldap-2.6.9-1.fc41.x86_64/openldap-2.6.9/libraries/libldap/tls_o.c:693
> #15 0x00007f50b7b65bf2 in ldap_int_tls_connect (ld=ld@entry=0x2a9b2430,
> conn=conn@entry=0x2a9b25d0, host=host@entry=0x2a9b2550 "192.168.133.56")
> at
> /usr/src/debug/openldap-2.6.9-1.fc41.x86_64/openldap-2.6.9/libraries/libldap/tls2.c:425
> #16 0x00007f50b7b6636f in ldap_int_tls_start (ld=0x2a9b2430, conn=0x2a9b25d0,
> srv=<optimized out>)
> at
> /usr/src/debug/openldap-2.6.9-1.fc41.x86_64/openldap-2.6.9/libraries/libldap/tls2.c:1245
> #17 0x00007f50b7b3d4c2 in ldap_int_open_connection (ld=0x2a9b2430,
> conn=0x2a9b25d0, srv=0x2a9b24d0, async=0)
> at
> /usr/src/debug/openldap-2.6.9-1.fc41.x86_64/openldap-2.6.9/libraries/libldap/open.c:515
> #18 0x00007f50b7b5212d in ldap_new_connection (ld=0x2a9b2430,
> srvlist=0x2a9b2878, use_ldsb=1, connect=<optimized out>, bind=0x0, m_req=0,
> m_res=0)
> at
> /usr/src/debug/openldap-2.6.9-1.fc41.x86_64/openldap-2.6.9/libraries/libldap/request.c:491
> #19 0x00007f50b7b3c7b4 in ldap_open_defconn (ld=0x2a9b2430)
> at
> /usr/src/debug/openldap-2.6.9-1.fc41.x86_64/openldap-2.6.9/libraries/libldap/open.c:42
> #20 0x00007f50b7b52ed8 in ldap_send_initial_request (ld=0x2a9b2430,
> msgtype=96, dn=0x4023a9 "cn=admin,dc=solace,dc=com", ber=0x2a9b2570, msgid=1)
> at
> /usr/src/debug/openldap-2.6.9-1.fc41.x86_64/openldap-2.6.9/libraries/libldap/request.c:131
> #21 0x00007f50b7b429b9 in ldap_sasl_bind (ld=0x2a9b2430, dn=0x4023a9
> "cn=admin,dc=solace,dc=com", mechanism=0x0, cred=0x7ffd1cf2eb90, sctrls=0x0,
> cctrls=0x0, msgidp=0x7ffd1cf2eb8c) at
> /usr/src/debug/openldap-2.6.9-1.fc41.x86_64/openldap-2.6.9/libraries/libldap/sasl.c:164
--
You are receiving this mail because:
You are on the CC list for the issue.
