[PATCH] s4/ldap: Fix nested searches SEGFAULT bug

Kamen Mazdrashki kamenim at gmail.com
Fri Jan 29 07:01:33 MST 2010

On Fri, Jan 29, 2010 at 15:42, simo <idra at samba.org> wrote:
> Nested ldap searches shouldn't cause this.
> Each search is ties to its own request, and each request on the wire has
> a specific id, so we correctly match replies with requests.
Yes, that's exactly what Tridge said when I pinged him about this issue :)
Requests are matched correctly.
It is the the code that handles LDAP_TAG_SearchResultEntry that causes
The problem is that when we fetch LDAP_TAG_SearchResultDone packet
from the wire,
ildb_callback() is executed again to handle this packet.
By this time, request is of type LDAP_TAG_SearchRequest, so we execute a for
cycle on all replies again.
First reply is the search result we are already handling, but the
function doesn't know that,
so it calls ldb_module_send_entry() with the data for the first reply
(i.e. calling search_result_callback() for the second time on the same reply).
Luckily, this line "ldbmsg->elements = talloc_move(ldbmsg,
NULL-ifies search->attributes member, so when this reply is handle for
the second time
ldbmsg->elements are NULL, and hence we got the SEGFAULT.

If you run the test without the fix it should be more clear?

> It looks like there seem to be either a misuse of the interface or a bug
> deep within it. Your fix, at first sight, looks like a bit of bandaid
> that covers a worse problem.
> Can you please show me the segfault you are getting ?
> It looks to me the test you made abuses the interface. I lean to think
> your callback is the cause of the segfault and not ldb_ildap code.
My search_callback() implementation is not 100% correct, you are right -
I am counting on fact that I know what ldb_search_default_callback() internal
implementation is. So I just switched the context so that
my do it's job. But doesn't abuse the interface in any way - just save
copy&paste few lines.

Kamen Mazdrashki
kamen.mazdrashki at postpath.com

More information about the samba-technical mailing list