The branch, v3-2-stable has been updated via ec6306db8f82f237ab3ebb9f1a4098dbc1cb05de (commit) via 64edcda438023c4c8d95f1cc5f70627bda357305 (commit) from 791a3a48fb1cacf1c3074e5a3d744be8b14f98e6 (commit)
http://gitweb.samba.org/?p=samba.git;a=shortlog;h=v3-2-stable - Log ----------------------------------------------------------------- commit ec6306db8f82f237ab3ebb9f1a4098dbc1cb05de Author: Karolin Seeger <[EMAIL PROTECTED]> Date: Mon Apr 28 10:01:12 2008 +0200 WHATSNEW: Add changes from Steven Danneman. Karolin (cherry picked from commit bfb91c078c28f528581058ba22d31c32616aa869) commit 64edcda438023c4c8d95f1cc5f70627bda357305 Author: Steven Danneman <[EMAIL PROTECTED](none)> Date: Fri Apr 25 18:34:46 2008 -0700 Fix bug 5419: memory leak in ads_do_search_all_args() when enumerating 1000s of entries The ads_do_search_all_args() function attempts to string together several LDAPMessage structures, returned across several paged ldap requests, into a single LDAPMessage structure. It does this by pulling entries off the second LDAPMessage structure and appending them to the first via the OpenLDAP specific ldap_add_result_entry() call. The problem with this approach is it skips non-entry messages such as the result, and controls. These messages are leaked. The short term solution as suggested by Volker is to replace the ads_*_entry() calls with ads_*_message() calls so we don't leak any messages. This fixes the leak but doesn't remove the dependence on the OpenLDAP specific implementation of ldap_add_result_entry(). (cherry picked from commit fe9f48bfe8d31812d9644682903c04f1e93c2987) ----------------------------------------------------------------------- Summary of changes: WHATSNEW.txt | 4 ++++ source/include/ads_protos.h | 2 ++ source/libads/ldap.c | 26 ++++++++++++++++++++++++-- 3 files changed, 30 insertions(+), 2 deletions(-) Changeset truncated at 500 lines: diff --git a/WHATSNEW.txt b/WHATSNEW.txt index 7c5153f..05abdc4 100644 --- a/WHATSNEW.txt +++ b/WHATSNEW.txt @@ -208,6 +208,10 @@ Changes since 3.2.0pre3: ----------------------- +o Steven Danneman <[EMAIL PROTECTED](none)> + * Bug 5419: Fix memory leak in ads_do_search_all_args() when enumerating + 1000s of entries + Changes since 3.2.0pre2: ----------------------- diff --git a/source/include/ads_protos.h b/source/include/ads_protos.h index 738df3e..a372010 100644 --- a/source/include/ads_protos.h +++ b/source/include/ads_protos.h @@ -89,6 +89,8 @@ ADS_STATUS ads_search_retry_sid(ADS_STRUCT *ads, LDAPMessage **res, LDAPMessage *ads_first_entry(ADS_STRUCT *ads, LDAPMessage *res); LDAPMessage *ads_next_entry(ADS_STRUCT *ads, LDAPMessage *res); +LDAPMessage *ads_first_message(ADS_STRUCT *ads, LDAPMessage *res); +LDAPMessage *ads_next_message(ADS_STRUCT *ads, LDAPMessage *res); void ads_process_results(ADS_STRUCT *ads, LDAPMessage *res, bool (*fn)(ADS_STRUCT *,char *, void **, void *), void *data_area); diff --git a/source/libads/ldap.c b/source/libads/ldap.c index b0f27b5..9321302 100644 --- a/source/libads/ldap.c +++ b/source/libads/ldap.c @@ -870,8 +870,8 @@ static ADS_STATUS ads_do_paged_search(ADS_STRUCT *ads, const char *bind_path, /* this relies on the way that ldap_add_result_entry() works internally. I hope that this works on all ldap libs, but I have only tested with openldap */ - for (msg = ads_first_entry(ads, res2); msg; msg = next) { - next = ads_next_entry(ads, msg); + for (msg = ads_first_message(ads, res2); msg; msg = next) { + next = ads_next_message(ads, msg); ldap_add_result_entry((LDAPMessage **)res, msg); } /* note that we do not free res2, as the memory is now @@ -2091,6 +2091,28 @@ int ads_count_replies(ADS_STRUCT *ads, void *res) } /** + * pull the first message from a ADS result + * @param ads connection to ads server + * @param res Results of search + * @return first message from result + **/ + LDAPMessage *ads_first_message(ADS_STRUCT *ads, LDAPMessage *res) +{ + return ldap_first_message(ads->ldap.ld, res); +} + +/** + * pull the next message from a ADS result + * @param ads connection to ads server + * @param res Results of search + * @return next message from result + **/ + LDAPMessage *ads_next_message(ADS_STRUCT *ads, LDAPMessage *res) +{ + return ldap_next_message(ads->ldap.ld, res); +} + +/** * pull a single string from a ADS result * @param ads connection to ads server * @param mem_ctx TALLOC_CTX to use for allocating result string -- Samba Shared Repository