Bug 458666

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