Hide Forgot
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.
Created attachment 313970 [details] diffs
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.
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
How can QE verify this? What to look for in the valgrind output?
(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()
verified 8.0 RHEL4-32, RHEL4-64, RHEL5-32, RHEL5-64
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
Created attachment 315149 [details] cvs commit log - HEAD