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

simo idra at samba.org
Fri Jan 29 06:42:54 MST 2010

On Fri, 2010-01-29 at 15:31 +0200, Kamen Mazdrashki wrote:
> Hi Simo,
> On Fri, Jan 29, 2010 at 15:13, simo <idra at samba.org> wrote:
> >
> > Kamen can you explain in what case a recursion can happen for the same
> > request ?
> > I need to understand what bug you are trying to fix here to say whether
> > or not this patch is a good idea.
> >
> The commit before the fix-commit implements such a test to reveal this bug?
> (But I guess you are not asking this right) :)
> Anyways, here is how I hit this bug in first place.
> I was implementing --show-binary for ms-prefixMap attribute value.
> It happens that bot Samba4 and AD use the same attribute, but with
> different format for data.
> Thus in ldif_write() function for prefixMap, I decided to check if the
> ldb_context is against Samba4
> implementation or against Windows AD - I made a search for
> "vendorName" in RootDSE.
> At this point I got SEGFAULT - it turns out this SEGFAULT happens in
> ldb_search_callback()
> implemented by ldbsearch utlity. SEGFAULT happens because when we read
> on the wire, we triger callback notification, which in turns
> mistakenly sends LDAP_SEARCH_RESULT
> value (which value we are alredy processing) again to the
> ldb_search_callback() function.
> It became a quite messy explanation, sorry for that...

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.

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.


Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>

More information about the samba-technical mailing list