[Date Prev][Date Next] [Chronological] [Thread] [Top]

(ITS#6793) Bad free in back-ldap when matchedDN changes



Full_Name: Hallvard B Furuseth
Version: RE24, HEAD
OS: Linux x86_64
URL: 
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard


ldap_back_search() can free rs->sr_matched after sending it.  That
breaks if something replaced rs->sr_matched during send_ldap_result().

Fixing to keep the matchedDN to free in a local variable.  (Could have
used REP_MATCHED_MUSTBEFREED, but might as well keep the logic which
tracks whether or not the value has a memory context.)

Also removing 'save_matched', cleaned up by result.c 1.313 (ITS#5340):
	/* FIXME: shouldn't this be null? */
	const char	*save_matched = rs->sr_matched;
Yes, it should be null.  Is it not, preserving it isn't helpful anyway.


To force a predictable matchedDN crash, let e.g. valsort produce an
unfreeable matchedDN:
Index: servers/slapd/overlays/valsort.c
@@ -274,2 +274,7 @@ valsort_response( Operation *op, SlapReply *rs )

+	if ( rs->sr_matched ) {
+		rs->sr_matched = "cn=bang";
+		rs->sr_flags  &= ~REP_MATCHED_MASK; /* do not free it */
+	}
+
 	/* If this is not a search response, or it is a syncrepl response,

Then provoke a matchedDN from the "remote" slapd and feed it to valsort:

slapd -d0 -h ldap://localhost:3890/ -f <config below>
database    monitor
database    ldap
suffix      cn=foo
uri         ldap://localhost:3890/
overlay     valsort
overlay     rwm
rwm-suffixmassage cn=foo cn=monitor

ldapsearch -xh localhost:3890 -b cn=hello,cn=foo