Full_Name: Greg Haverkamp Version: 2.4.31 OS: RHEL 6.2/OS X 10.7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.3.10.46)

When a request to a massaged suffix is made of back-ldap/slapo-rwm with a malformed filter, slapd crashes on the two tested platforms (RHEL 6.2/OS X 10.7). The last bits of the debug log and the backtrace are below:

[New Thread 0x7ffff640c700 (LWP 4520)] 4fcd62a8 >>> slap_listener(ldap://*:3389) 4fcd62a8 connection_get(13) 4fcd62a8 connection_get(13): got connid=1000 4fcd62a8 connection_read(13): checking for input on id=1000 ber_get_next ldap_read: want=8, got=8 0000: 30 44 02 01 01 63 3f 04 0D...c?. ldap_read: want=62, got=62 0000: 0a 63 6e 3d 65 78 61 6d 70 6c 65 0a 01 02 0a 01 .cn=example..... 0010: 00 02 01 00 02 01 00 01 01 00 a3 13 04 04 66 6f ..............fo 0020: 6f 20 04 0b 67 61 68 61 76 65 72 6b 61 6d 70 30 o ..gahaverkamp0 0030: 0d 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 ...objectClass ber_get_next: tag 0x30 len 68 contents: 4fcd62a8 op tag 0x63, time 1338860200 ber_get_next ldap_read: want=8 error=Resource temporarily unavailable 4fcd62a8 conn=1000 op=0 do_search ber_scanf fmt ({miiiib) ber: 4fcd62a8 >>> dnPrettyNormal: <cn=example> => ldap_bv2dn(cn=example,0) <= ldap_bv2dn(cn=example)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=example)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=example)=0 4fcd62a8 <<< dnPrettyNormal: <cn=example>, <cn=example> 4fcd62a8 SRCH "cn=example" 2 04fcd62a8 0 0 0 ber_scanf fmt ({mm}) ber: 4fcd62a8 filter: (?foo =gahaverkamp) ber_scanf fmt ({M}}) ber: 4fcd62a8 attrs:4fcd62a8 objectClass4fcd62a8 4fcd62a8 ==> limits_get: conn=1000 op=0 self="[anonymous]" this="cn=example" 4fcd62a8 ==> rewrite_context_apply [depth=1] string='cn=example' 4fcd62a8 ==> rewrite_rule_apply rule='((.+),)?cn=example$' string='cn=example' [1 pass(es)] 4fcd62a8 ==> rewrite_context_apply [depth=1] res={0,'dc=lbl,dc=gov'} 4fcd62a8 [rw] searchDN: "cn=example" -> "dc=lbl,dc=gov" 4fcd62a8 >>> dnPrettyNormal: <dc=lbl,dc=gov> => ldap_bv2dn(dc=lbl,dc=gov,0) <= ldap_bv2dn(dc=lbl,dc=gov)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=lbl,dc=gov)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=lbl,dc=gov)=0 4fcd62a8 <<< dnPrettyNormal: <dc=lbl,dc=gov>, <dc=lbl,dc=gov> 4fcd62a8 ==> rewrite_context_apply [depth=1] string='(foo =gahaverkamp)' 4fcd62a8 ==> rewrite_context_apply [depth=1] res={0,'NULL'} [rw] searchFilter: "(foo =gahaverkamp)" -> "(foo =gahaverkamp)" put_filter: "(foo =gahaverkamp)" put_filter: simple put_simple_filter: "foo =gahaverkamp" 4fcd62a8 send_ldap_result: conn=1000 op=0 p=3 4fcd62a8 send_ldap_result: err=0 matched="" text="massaged filter parse error" 4fcd62a8 send_ldap_response: msgid=1 tag=101 err=0 ber_flush2: 41 bytes to sd 13 ldap_write: want=41, written=41 0000: 30 27 02 01 01 65 22 0a 01 00 04 00 04 1b 6d 61 0'...e".......ma 0010: 73 73 61 67 65 64 20 66 69 6c 74 65 72 20 70 61 ssaged filter pa 0020: 72 73 65 20 65 72 72 6f 72 rse error

Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff640c700 (LWP 4520)] 0x0000003f6987a31c in free () from /lib64/libc.so.6 Missing separate debuginfos, use: debuginfo-install cyrus-sasl-gssapi-2.1.23-13.el6.x86_64 cyrus-sasl-lib-2.1.23-13.el6.x86_64 cyrus-sasl-plain-2.1.23-13.el6.x86_64 db4-4.7.25-16.el6.x86_64 glibc-2.12-1.47.el6_2.5.x86_64 keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6_2.1.x86_64 libcom_err-1.41.12-11.el6.x86_64 libselinux-2.0.94-5.2.el6.x86_64 nss-softokn-freebl-3.12.9-11.el6.x86_64 openssl-1.0.0-20.el6_2.1.x86_64 zlib-1.2.3-27.el6.x86_64 (gdb) bt #0 0x0000003f6987a31c in free () from /lib64/libc.so.6 #1 0x000000000043ca3e in ava_free (op=0x7fffe8002970, ava=0x7fffe8002e50, freeit=1) at ava.c:50 #2 0x000000000042453a in filter_free_x (op=0x7fffe8002970, f=0x7fffe8002ed0, freeme=1) at filter.c:531 #3 0x0000000000423127 in do_search (op=0x7fffe8002970, rs=0x7ffff640b950) at search.c:260 #4 0x0000000000420cfb in connection_operation (ctx=0x7ffff640bab0, arg_v=0x7fffe8002970) at connection.c:1150 #5 0x00000000004214d5 in connection_read_thread (ctx=0x7ffff640bab0, argv=<value optimized out>) at connection.c:1286 #6 0x000000000050cc30 in ldap_int_thread_pool_wrapper (xpool=0x8809a0) at tpool.c:688 #7 0x0000003f69c077f1 in start_thread () from /lib64/libpthread.so.0 #8 0x0000003f698e592d in clone () from /lib64/libc.so.6

ldapsearch takes care of handling the bad search filter. However, the problem arose when one of our developers miscoded the search filter (badly). A short bit of Jython (utilizing the UnboundID ldap sdk) that can cause the crash is here:

from com.unboundid.ldap.sdk import LDAPConnection from com.unboundid.ldap.sdk import SearchScope from com.unboundid.ldap.sdk import SearchResult from com.unboundid.ldap.sdk import LDAPURL

attributes = ['objectClass'] ldap_url = "ldap://10.0.228.135:3389" url = LDAPURL(ldap_url)

ldap_conn = LDAPConnection(url.getHost(), url.getPort())

#search_result = ldap_conn.search('ou=people,o=lawrence berkeley laboratory,c=us', SearchScope.SUB, '(?uid = 'gahaverkamp')', attributes) search_result = ldap_conn.search('cn=example', SearchScope.SUB, '(foo =gahaverkamp)', attributes)

entries = search_result.getSearchEntries()

The actual contents of the filter don't seem to matter too much, so long as filter is bad. The original one sent by the developer resembles the commented line in the script above.