https://bugs.openldap.org/show_bug.cgi?id=10302
Issue ID: 10302
Summary: Double free of idcursor
Product: OpenLDAP
Version: 2.6.6
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Created attachment 1050
--> https://bugs.openldap.org/attachment.cgi?id=1050&action=edit
proposed patch, which was created from current master, but also applies to
2.6.6
While switching from Oracle Linux (a RHEL clone) 8 to 9 one of our larger LDAP
samples started causing a double free error at the end of the slapadd run.
While I can't share the LDIF in question and it didn't consistently cause the
issue, only every 5-6 times it ran, I could ran gdb and valgrind on it and
suggest the attached patch that resolves that error to re-occur. I validated
the patch still applies to the current master branch of openldap, as well as to
2.6.6 on EL9 where we encountered this.
The error originally observed was this (commands being run as ldap user):
[...]
rm -r /var/lib/ldap
mkdir /var/lib/ldap
slapadd -l /tmp/lz_vault_convert_add.ldif -q -w -n 2
PROXIED attributeDescription "LZVAULTPROFILECOUNT" inserted.
PROXIED attributeDescription "LZVAULTGLOBALPROFILECOUNT" inserted.
-#################### 100.00% eta none elapsed 03s spd 4.2 M/s
Closing DB...double free or corruption (!prev)
Under valgrind, the following trace could be observed:
valgrind --vgdb=full --leak-check=full --show-leak-kinds=all
--track-origins=yes slapadd -l /tmp/lz_vault_convert_add.ldif -q -w -n 2
==502== Memcheck, a memory error detector
==502== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==502== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info
==502== Command: slapadd -l /tmp/lz_vault_convert_add.ldif -q -w -n 2
==502==
PROXIED attributeDescription "LZVAULTPROFILECOUNT" inserted.
PROXIED attributeDescription "LZVAULTGLOBALPROFILECOUNT" inserted.
==502== Invalid read of size 8
==502== at 0x1E65A9: mdb_cursor_close (mdb.c:7764)
==502== by 0x1F71B8: UnknownInlinedFun (tools.c:202)
==502== by 0x1F71B8: mdb_tool_entry_close (tools.c:152)
==502== by 0x1D8291: slapadd (slapadd.c:511)
==502== by 0x1348C6: main (main.c:540)
==502== Address 0x188c8af8 is 8 bytes inside a block of size 392 free'd
==502== at 0x4847B4C: free (vg_replace_malloc.c:989)
==502== by 0x22CEFE: mdb_cursors_close.isra.0 (mdb.c:2638)
==502== by 0x1EBAAE: mdb_txn_commit (mdb.c:3640)
==502== by 0x1F75E2: mdb_tool_entry_modify (tools.c:1066)
==502== by 0x1D9AF9: slap_tool_update_ctxcsn.part.0 (slapcommon.c:1069)
==502== by 0x1D8440: UnknownInlinedFun (slapcommon.c:962)
==502== by 0x1D8440: slapadd (slapadd.c:502)
==502== by 0x1348C6: main (main.c:540)
==502== Block was alloc'd at
==502== at 0x484482F: malloc (vg_replace_malloc.c:446)
==502== by 0x1E8699: mdb_cursor_open (mdb.c:7690)
==502== by 0x1F8C45: mdb_tool_entry_put (tools.c:707)
==502== by 0x1D8150: slapadd (slapadd.c:453)
==502== by 0x1348C6: main (main.c:540)
[...]
Please advise if I can provide any further diagnostics, while I can still
relatively easily reproduce the issue.
--
You are receiving this mail because:
You are on the CC list for the issue.
