Logged in as guest
Viewing Software Bugs/7496 Full headers
Major security issue: yes no
Notes: fixed in master fixed in RE24 Notification:
Date: Tue, 22 Jan 2013 09:15:04 +0000 From: meike.stone@googlemail.com To: openldap-its@OpenLDAP.org Subject: Segemtation fault in mdb_entry_decode
Full_Name: Meike Stone Version: 2.4.33 and git OS: Linux / SLES11 SP2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.200.138.3) I use a Database with about 1,500,000 entires and 2,5GByte ldif from slapcat. This database was exported from our production system running bdb-backend. The Problem exist in Version 2.4.33, therefore I took the slapd source from git (2013/01/21) and I compiled slapd with debugging symbols. My test configuration is simple: -------------------------------------------- include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/yast.schema include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/my_ldap_attributes.schema include /etc/openldap/schema/my_ldap_ObjectClasses.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args sizelimit -1 timelimit 300 disallow bind_anon require authc gentlehup on tool-threads 4 serverID 001 ############################ # mdb database definitions ############################ database mdb suffix "ou=root" rootdn "cn=admin,ou=root" rootpw password directory /var/lib/ldap/ldap.mdb loglevel 256 maxsize 10737418240 envflags writemap,nometasync index objectClass,entryUUID,entryCSN eq index cn eq,sub . . . some other own indexes here -------------------------------------------- I started my search via: /tmp/ol/usr/local/bin/ldapsearch -x -h localhost -w password -D cn=admin,ou=root -b'ou=root' '(objectClass=*)' >/dev/null and got in the syslog following meassge: Jan 21 17:50:31 debld02 kernel: [348860.053152] slapd[19394]: segfault at 7f760f974ce8 ip 000000000053bea1 sp 00007f738b10a650 error 4 in slapd [400000+227000] Because of this, I configured the kernel to core dump: sysctl -w kernel.core_pattern=/tmp/core sysctl -w kernel.core_uses_pid=1 sysctl -w kernel.suid_dumpable=2 ulimit -c unlimited ulimit -v unlimited Here is the output from Backtrace: (gdb) bt #0 0x000000000053bea1 in mdb_entry_decode (op=0xc3a020, data=0x7f738b10a770, e=0x7f738b11a828) at id2entry.c:666 #1 0x0000000000501d30 in mdb_search (op=0xc3a020, rs=0x7f738b21ba30) at search.c:720 #2 0x0000000000433d41 in fe_op_search (op=0xc3a020, rs=0x7f738b21ba30) at search.c:402 #3 0x0000000000433647 in do_search (op=0xc3a020, rs=0x7f738b21ba30) at search.c:247 #4 0x00000000004300f5 in connection_operation (ctx=0x7f738b21bb80, arg_v=0xc3a020) at connection.c:1150 #5 0x0000000000430694 in connection_read_thread (ctx=0x7f738b21bb80, argv=0x9) at connection.c:1286 #6 0x0000000000566c0b in ldap_int_thread_pool_wrapper (xpool=0x8ef460) at tpool.c:688 #7 0x00007f760ddd67b6 in start_thread () from /lib64/libpthread.so.0 #8 0x00007f760db31c5d in clone () from /lib64/libc.so.6 #9 0x0000000000000000 in ?? () ======================================== (gdb) bt full #0 0x000000000053bea1 in mdb_entry_decode (op=0xc3a020, data=0x7f738b10a770, e=0x7f738b11a828) at id2entry.c:666 have_nval = 0 mdb = 0x7f760eff4010 i = 0 j = 0 nattrs = 2600 nvals = 524289 rc = 32627 a = 0x7f73886fa060 x = 0x7f73886fa010 text = 0x1 <Address 0x1 out of bounds> ad = 0x11a561 lp = 0x7f74bbb99738 ptr = 0x7f74bbb99738 <Address 0x7f74bbb99738 out of bounds> bptr = 0x7f73887187e0 #1 0x0000000000501d30 in mdb_search (op=0xc3a020, rs=0x7f738b21ba30) at search.c:720 scopeok = 1 edata = {mv_size = 0, mv_data = 0x7f74bbb99728} mdb = 0x7f760eff4010 id = 1156449 cursor = 1156449 lastid = 18446744073709551615 candidates = {18446744073709551615, 1, 18446744073709551615, 0 <repeats 130260 times>, 140145012714441, 0, 140145012852253, 8589940736, 0, 1102570112642121728, 140134232198960, 0, 0, 4294969344, 0, 144115737831604224, 140134232199008, 0, 0, 4294969344, 0, 72058143793676288, 0, 0, 140145012852253, 562962838323220, 83263594790786, 4294967296, 72058139498840072, 72058139498905608, 18446743519659032584, 122509647347719, 563035852767288, 83263594790786, 8564836354, 144115733536768008, 144115733536833544, 18446743519659032584, 122509647347719, 563035852767292, 83263594790786, 8598329346, 1102570108347285512, 1102570108347351048, 18396392677450186760, 3488165888539164681, 0 <repeats 252 times>, 140145015511498, 24, 140134232201360, 140134232201280, 0, 0, 0, 2050, 0, 0, 0, 0, 140134232201392, 140134240594784, 5912807, 0, 38654705665, 0, 8804682956800, 140134232205552, 5910925, 4294967296, 140144980134384,
Date: Tue, 22 Jan 2013 12:23:36 +0000 From: Howard Chu <hyc@symas.com> To: meike.stone@googlemail.com, openldap-its@openldap.org Subject: Re: (ITS#7496) Segemtation fault in mdb_entry_decode
meike.stone@googlemail.com wrote: > Full_Name: Meike Stone > Version: 2.4.33 and git > OS: Linux / SLES11 SP2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.200.138.3) > > > I use a Database with about 1,500,000 entires and 2,5GByte ldif from slapcat. > This database was exported from our production system running bdb-backend. > > The Problem exist in Version 2.4.33, therefore I took the slapd source from git > (2013/01/21) and I compiled slapd with debugging symbols. > Thread 1 (Thread 0x7f738b21c700 (LWP 19394)): > #1 0x0000000000501d30 in mdb_search (op=0xc3a020, rs=0x7f738b21ba30) at > search.c:720 > scopeok = 1 > edata = {mv_size = 0, mv_data = 0x7f74bbb99728} This indicates that the entry being debugged is actually zero bytes, i.e. it's not a valid entry at all. Nodes like this get stored in the database during slapadd when a child entry gets added before its parent; a zero-byte stub is stored as a placeholder for the missing parent. When you ran slapadd you should have seen warning messages about missing entries, telling you that your LDIF is incomplete. We can prevent the SEGV but your database is still invalid because your LDIF is invalid. > mdb = 0x7f760eff4010 > id = 1156449 > cursor = 1156449 > lastid = 18446744073709551615 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Date: Thu, 24 Jan 2013 14:18:37 +0100 Subject: Re: (ITS#7496) Segemtation fault in mdb_entry_decode From: Meike Stone <meike.stone@googlemail.com> To: Howard Chu <hyc@symas.com> Cc: openldap-its@openldap.org
>> Thread 1 (Thread 0x7f738b21c700 (LWP 19394)): > > >> #1 0x0000000000501d30 in mdb_search (op=0xc3a020, rs=0x7f738b21ba30) at >> search.c:720 >> scopeok = 1 >> edata = {mv_size = 0, mv_data = 0x7f74bbb99728} > > > This indicates that the entry being debugged is actually zero bytes, i.e. > it's not a valid entry at all. Nodes like this get stored in the database > during slapadd when a child entry gets added before its parent; a zero-byte > stub is stored as a placeholder for the missing parent. > When you ran slapadd > you should have seen warning messages about missing entries, telling you > that your LDIF is incomplete. Yes you are right, I repeated the import via slapcat to test and got this error message: ~ # slapadd -w -q -f /etc/openldap/slapd.conf -l /backup.ldif 50f98421 mdb_monitor_db_open: monitoring disabled; configure monitor database to enable -#################### 100.00% eta none elapsed 09m18s spd 4.6 M/s Closing DB...Error, entries missing! entry 1156449: cn=1356155776-83002,ou=... ,... ,ou=root (I shortened the entry DN in output with "...") I recognized this message before, but thought the entry was not imported ... > > We can prevent the SEGV but your database is still invalid because your LDIF > is invalid. Yes, will ask in the mailing list for additional information not directly releated to this SEGV. Thanks Kindly regards Maike
______________ © Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org
