The first leak happens when password policy is active and trivial words checking is being used, and the password is being modified. When getting the list of attribute from the existing entry in the modify case, the function slapi_attr_get_valueset is used - this function makes a duplicate of the valueset and overwrites the valueset argument - vs must be freed first before calling this function. The second leak happens when the password storage scheme is changed. The function check_pw_storagescheme_value uses pw_name2scheme to check the given scheme - this function allocates a struct pw_scheme * which must be freed with free_pw_scheme.
Created attachment 313965 [details] diffs
This leak can be triggered by an anonymous user. The check_trivial_words check is done before access control is applied. The way to mitigate this issue is to disable trivial words checking - if that's not possible, then password syntax checking must be disabled to avoid this leak.
The check_pw_storagescheme_value leak can only be triggered by an authenticated, authorized user, changing the password storage setting in the fine grained password policy configuration.
Your fixes look good. Anoter idea for the first leak, "line 1289 vs = slapi_valueset_new();" may be called after line 1302 only when vs is NULL. Then, we could save one extra malloc and free (although it's a tiny save...)
Created attachment 314016 [details] new diffs
(In reply to comment #4) > Your fixes look good. > > Anoter idea for the first leak, "line 1289 vs = slapi_valueset_new();" may be > called after line 1302 only when vs is NULL. Then, we could save one extra > malloc and free (although it's a tiny save...) Thanks. Patch updated.
Created attachment 314147 [details] cvs commit log - DS8.0 Reviewed by: nkinder, nhosoi (Thanks!) Fix Description: The first leak happens when password policy is active and trivial words checking is being used, and the password is being modified. When getting the list of attribute from the existing entry in the modify case, the function slapi_attr_get_valueset is used - this function makes a duplicate of the valueset and overwrites the valueset argument. The fix is to move the allocation of vs until after the call to slapi_attr_get_valueset, and only allocate it if it is non NULL. The second leak happens when the password storage scheme is changed. The function check_pw_storagescheme_value uses pw_name2scheme to check the given scheme - this function allocates a struct pw_scheme * which must be freed with free_pw_scheme. Platforms tested: RHEL5, Fedora 8 Flag Day: no Doc impact: no QA impact: already covered by acceptance tests New Tests integrated into TET: none
How can QE verify this? What to look for in the valgrind output?
(In reply to comment #9) > How can QE verify this? What to look for in the valgrind output? Look for a memory leak in check_trivial_words() and in check_pw_storagescheme_value()
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 315147 [details] cvs commit log - HEAD