[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 SEGFAULT.
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,
&search->attributes);"
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
ldb_search_default_callback()
my do it's job. But doesn't abuse the interface in any way - just save
copy&paste few lines.


-- 
CU,
Kamen Mazdrashki
kamen.mazdrashki at postpath.com
http://repo.or.cz/w/Samba/kamenim.git
-------------------------------------
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/


More information about the samba-technical mailing list