Bug 1086904 - mem leak in do_search - rawbase not freed upon certain errors
Summary: mem leak in do_search - rawbase not freed upon certain errors
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.1
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
Depends On:
TreeView+ depends on / blocked
Reported: 2014-04-11 19:29 UTC by Noriko Hosoi
Modified: 2015-03-05 09:34 UTC (History)
3 users (show)

Fixed In Version: 389-ds-base-
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.
Clone Of: 1086903
Last Closed: 2015-03-05 09:34:22 UTC
Target Upstream Version:

Attachments (Terms of Use)
valgrind output (84.51 KB, text/plain)
2015-01-09 15:13 UTC, Viktor Ashirov
no flags Details
valgrind output (70.53 KB, text/plain)
2015-01-09 15:37 UTC, Viktor Ashirov
no flags Details

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0416 normal SHIPPED_LIVE Important: 389-ds-base security, bug fix, and enhancement update 2015-03-05 14:26:33 UTC

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:


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

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 

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.


Note You need to log in before you can comment on or make changes to this bug.