[Fedora-directory-commits] ldapserver/ldap/servers/slapd/back-ldbm sort.c, 1.5, 1.6

[Richard Allen Megginson (rmeggins)]

Author: rmeggins

Update of /cvs/dirsec/ldapserver/ldap/servers/slapd/back-ldbm
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv4860/ldapserver/ldap/servers/slapd/back-ldbm

Modified Files:
	sort.c 
Log Message:
Bug(s) fixed: 179135
Bug Description: memory leaks using ber_scanf when handling bad BER packets
Reviewed by: All (Thanks!)
Files: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=123783
Branch: HEAD
Fix Description: 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179135#c0
I basically did a search through our code for all calls to ber_scanf, 
ber_get_stringa, and ber_get_stringal and made sure we properly free any 
arguments that may have been allocated.  There was a bug in the ldapsdk 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179135 that causes 
us to free uninitialized memory when trying to clean up the result of 
ber_get_stringal (or ber_scanf with 'V').  I had to initialize some 
variables to NULL so that we could properly clean them up, and added 
some additional clean ups that were missing.  Also, in repl_extop.c, we 
were calling free on an array that we should have been calling 
ch_array_free on.  Yet another lesson in the evils of slapi_ch_free and 
disabling compiler type checks in general.
Platforms tested: Fedora Core 4
Flag Day: no
Doc impact: no



Index: sort.c
===================================================================
RCS file: /cvs/dirsec/ldapserver/ldap/servers/slapd/back-ldbm/sort.c,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- sort.c	19 Apr 2005 22:07:38 -0000	1.5
+++ sort.c	23 Feb 2006 20:45:22 -0000	1.6
@@ -384,6 +384,7 @@
 
 		return_value = ber_scanf(ber,"a",&rtype);
 		if (LBER_ERROR == return_value) {
+			slapi_ch_free_string(&rtype);
 			rc = LDAP_PROTOCOL_ERROR;
                         goto err;
 		}