Bug 458675 - Memory leaks in valueset code
Summary: Memory leaks in valueset code
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: 389
Classification: Retired
Component: Directory Server
Version: 1.1.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Chandrasekar Kannan
URL:
Whiteboard: comment#1.review+nhosoi
Depends On:
Blocks: 249650 FDS112 453229 CVE-2008-3283
TreeView+ depends on / blocked
 
Reported: 2008-08-11 14:25 UTC by Rich Megginson
Modified: 2015-01-04 23:33 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-08-27 20:39:18 UTC


Attachments (Terms of Use)
diffs (2.99 KB, patch)
2008-08-11 14:38 UTC, Rich Megginson
no flags Details | Diff
cvs commit log - DS8.0 (181 bytes, text/plain)
2008-08-12 22:29 UTC, Rich Megginson
no flags Details
cvs commit log - HEAD (1.65 KB, text/plain)
2008-08-27 21:09 UTC, Rich Megginson
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2008:0602 0 normal SHIPPED_LIVE Moderate: redhat-ds-base and redhat-ds-admin security and bug fix update 2008-08-27 20:38:30 UTC

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


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