Bug 1086904

Summary: mem leak in do_search - rawbase not freed upon certain errors
Product: Red Hat Enterprise Linux 7 Reporter: Noriko Hosoi <nhosoi>
Component: 389-ds-baseAssignee: Noriko Hosoi <nhosoi>
Status: CLOSED ERRATA QA Contact: Viktor Ashirov <vashirov>
Severity: unspecified Docs Contact:
Priority: low    
Version: 7.1CC: nkinder, rmeggins, vashirov
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 389-ds-base-1.3.3.1-1.el7 Doc Type: Bug Fix
Doc Text:
Cause: If search failed at the early phase, the memory storing the given basedn was not freed. Consequence: The memory for the basedn leaked. Fix: Fixed the leak. Result: The basedn does not leak any more even if the search fails at the early phase.
 Story Points: ---
Clone Of: 1086903 Environment:
Last Closed: 2015-03-05 09:34:22 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
valgrind output
none
valgrind output none

Description Noriko Hosoi 2014-04-11 19:29:37 UTC 
+++ This bug was initially created as a clone of Bug #1086903 +++

Description of problem:
If there is some sort of error in do_search - decoding or protocol errors - after the rawbase variable is allocated but before it is assigned to SLAPI_ORIGINAL_TARGET_DN in pb, the cleanup code will get the NULL variable from the pb and free it, leaking rawbase.
Comment 1 Noriko Hosoi 2014-06-19 16:46:06 UTC 
Verify steps:

https://bugzilla.redhat.com/show_bug.cgi?id=1086903#c3
Comment 3 Jenny Severance 2014-10-21 20:07:50 UTC 
see RHEL 6.6 bug for verification steps
Comment 4 Viktor Ashirov 2015-01-09 15:13:25 UTC 
Created attachment 978191 [details]
valgrind output

$ rpm -qa | grep 389
389-ds-base-1.3.3.1-11.el7.x86_64
389-ds-base-libs-1.3.3.1-11.el7.x86_64

in cn=config:
nsslapd-allow-anonymous-access: off
nsslapd-minssf: 128

CA certificate exported for a client:
$ cat .ldaprc 
TLS_CACERT /tmp/rhel7dscacert.asc

[1] Search with invalid base dn

$ ldapsearch -LLL -D "cn=Directory Manager" -w Secret123 -b dc=example,dc=foo -H ldaps://localhost:636 
No such object (32)

[2] Configure the server to prohibit anonymous search. Then search anonymously.

$ ldapsearch -LLL -b dc=example,dc=com -H ldaps://localhost:636 
ldap_sasl_interactive_bind_s: Inappropriate authentication (48)
	additional info: Anonymous access is not allowed.

[3] Configure the server with high minimum SSF. Then search with simple auth.

$ ldapsearch -LLL -D "cn=Directory Manager" -w Secret123 -b dc=example,dc=com  -H ldap://localhost:389
ldap_bind: Server is unwilling to perform (53)
	additional info: Minimum SSF not met.

$ sudo /usr/sbin/stop-dirsrv 
Stopping instance "rhel7ds"

$ grep -i do_search /tmp/valgrind-20150109-160503-rhel7ds.out | wc -l 
0

Marking as VERIFIED
Comment 5 Viktor Ashirov 2015-01-09 15:37:37 UTC 
Created attachment 978218 [details]
valgrind output

I'm sorry, I was running valgrind without debuginfo package for 389-ds. 
I repeated the tests with debuginfo installed. No do_search in the output.
Comment 7 errata-xmlrpc 2015-03-05 09:34:22 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-0416.html