Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 458675

Summary: Memory leaks in valueset code
Product: [Retired] 389 Reporter: Rich Megginson <rmeggins>
Component: Directory ServerAssignee: Rich Megginson <rmeggins>
Status: CLOSED ERRATA QA Contact: Chandrasekar Kannan <ckannan>
Severity: medium Docs Contact:
Priority: medium    
Version: 1.1.1CC: benl, jgalipea, jlieskov, nhosoi, nkinder, security-response-team
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: comment#1.review+nhosoi
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-08-27 20:39:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 249650, 452721, 453229, 458977    
Attachments:
Description Flags
diffs
none
cvs commit log - DS8.0
none
cvs commit log - HEAD none

Description Rich Megginson 2008-08-11 14:25:30 UTC
The first leak occurs when you are using replication and you add values to an attribute that were previously deleted - that is, the values that you want to add are on the attribute's deleted values list and are being "resurrected".  This leak is caused by an improper bit test (foo & bar|baz).  The or | has higher precedence and is evaluated first.  The fix is to use parentheses (foo & (bar|baz)).
The second leak is caused when several values are being added to an attribute, and the list contains non-sequential duplicate values (e.g. foo, bar, baz, foo).  The code uses an array of Slapi_Value* called keyvals.  When a valid value is found, the Slapi_Value* is moved from keyvals to valuetreep and the keyvals array index is set to NULL.  This array is passed to valuearray_free to free the individual Slapi_Value* and the array itself.  This works fine in the non-error case because there are no Slapi_Value* elements to free, so it just frees the array.  However, in the duplicate value case, some of the elements have already been set to NULL, so those are skipped over by valuearray_free.  The fix is to introduce a new function valuearray_free_ext that takes an additional argument which is the array index to start freeing from.  That way the non-NULL Slapi_Value* elements can be freed along with the array itself.

Comment 1 Rich Megginson 2008-08-11 14:38:10 UTC
Created attachment 313970 [details]
diffs

Comment 2 Rich Megginson 2008-08-11 16:47:15 UTC
These leaks can only be triggered by an authenticated user who has the ability to add/modify attributes to an entry.  You also have to be using replication.  This bug can be mitigated by turning off the selfwrite access control and by making sure only administrative users can write.

Comment 3 Rich Megginson 2008-08-12 22:29:52 UTC
Created attachment 314149 [details]
cvs commit log - DS8.0

Reviewed by: nkinder,nhosoi (Thanks!)
Fix Description: This leak is caused when several values are being added to an attribute,
and the list contains non-sequential duplicate values (e.g. foo, bar, baz,
foo).  The code uses an array of Slapi_Value* called keyvals.  When a valid
value is found, the Slapi_Value* is moved from keyvals to valuetreep and the
keyvals array index is set to NULL.  This array is passed to valuearray_free to
free the individual Slapi_Value* and the array itself.  This works fine in the
non-error case because there are no Slapi_Value* elements to free, so it just
frees the array.  However, in the duplicate value case, some of the elements
have already been set to NULL, so those are skipped over by valuearray_free.
The fix is to introduce a new function valuearray_free_ext that takes an
additional argument which is the array index to start freeing from.  That way
the non-NULL Slapi_Value* elements can be freed along with the array itself.
Platforms tested: RHEL5, Fedora 8
Flag Day: no
Doc impact: no
QA impact: should be covered by regular nightly and manual testing
New Tests integrated into TET: none

Comment 5 Jenny Severance 2008-08-19 20:30:40 UTC
How can QE verify this?  What to look for in the valgrind output?

Comment 6 Rich Megginson 2008-08-19 20:41:55 UTC
(In reply to comment #5)
> How can QE verify this?  What to look for in the valgrind output?

Look for leaks in valuetree_add_valuearray() or entry_add_present_values_wsi()

Comment 7 Jenny Severance 2008-08-21 17:48:18 UTC
verified 8.0 RHEL4-32, RHEL4-64, RHEL5-32, RHEL5-64

Comment 10 errata-xmlrpc 2008-08-27 20:39:18 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2008-0602.html

Comment 11 Rich Megginson 2008-08-27 21:09:54 UTC
Created attachment 315149 [details]
cvs commit log - HEAD