Scott,
On Mon, Nov 13, 2006 at 07:59:59AM -0800, Scott Anderson wrote:
> (gdb) thread apply all bt
> Thread 1 (Thread -1210202432 (LWP 17387)):
> #0 0xb7fa5410 in ?? ()
> #1 0xbf81b020 in ?? ()
> #2 0x00000006 in ?? ()
> #3 0x000043eb in ?? ()
> #4 0xb7e47821 in raise () from /lib/tls/i686/cmov/libc.so.6
> #5 0xb7e48fb9 in abort () from /lib/tls/i686/cmov/libc.so.6
> #6 0xb7e40fcf in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
> #7 0xb7f9bed7 in ber_free_buf () from /usr/lib/liblber.so.2
> #8 0xb7f9bf1f in ber_free () from /usr/lib/liblber.so.2
> #9 0xb7cba9ed in ldap_msgfree () from /usr/lib/libldap_r.so.2
> #10 0xb7ce8b57 in do_result (ctx=0x806b838, all=0) at ldap-nss.c:2440
> #11 0xb7ce839c in _nss_ldap_ent_context_init_locked (pctx=0xb7cf9bb0)
> at ldap-nss.c:2012
> #12 0xb7ce82f2 in _nss_ldap_ent_context_init (pctx=0xb7cf9bb0)
> at ldap-nss.c:1970
> #13 0xb7cebc88 in _nss_ldap_setpwent () at ldap-pwd.c:246
> #14 0xb7efc757 in __nss_database_lookup () from /lib/tls/i686/cmov/libc.so.6
> #15 0xb7eab401 in getpwent_r () from /lib/tls/i686/cmov/libc.so.6
> #16 0xb7efc2b6 in __nss_database_lookup () from /lib/tls/i686/cmov/libc.so.6
> #17 0xb7eab09a in getpwent () from /lib/tls/i686/cmov/libc.so.6
> #18 0x0804ab65 in ?? ()
> #19 0xbf81dc08 in ?? ()
> #20 0x08067d68 in ?? ()
> #21 0xb7fa11b4 in ?? () from /usr/lib/liblber.so.2
> #22 0xbf81b2f0 in ?? ()
> #23 0xb7f9de7a in ber_memvfree () from /usr/lib/liblber.so.2
> #24 0x0804b5db in ?? ()
> #25 0x00000000 in ?? ()
Great, this is helpful; enough so that I think I've been able to find the
bug, because I see an obvious double-free of the ldap message in this part
of the code.
Please give http://people.debian.org/~vorlon/libnss-ladp_251-7.1_i386.deb a
try; it's again built with debugging symbols, so even if it doesn't work for
you it should give us further good backtraces for debugging.
Stephen, I'm also attaching the current debdiff to this mail -- it can also
be found at http://people.debian.org/~vorlon/libnss-ldap-366172.diff.
BTW, Scott, I don't think we ever asked you what LDAP server you're using --
but your hostnames suggest that it's an eDirectory server, is this the case?
I'm starting to suspect we would have had a hard time ever reproducing this
bug testing against OpenLDAP. :)
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
diff -u libnss-ldap-251/ldap-nss.c libnss-ldap-251/ldap-nss.c
--- libnss-ldap-251/ldap-nss.c
+++ libnss-ldap-251/ldap-nss.c
@@ -2001,10 +2001,6 @@
}
else
{
- if (ctx->ec_res != NULL)
- {
- ldap_msgfree (ctx->ec_res);
- }
if (ctx->ec_cookie != NULL)
{
ber_bvfree (ctx->ec_cookie);
@@ -2013,6 +2009,10 @@
{
ldap_abandon (__session.ls_conn, ctx->ec_msgid);
}
+ if (ctx->ec_res != NULL)
+ {
+ ldap_msgfree (ctx->ec_res);
+ }
}
ctx->ec_cookie = NULL;
diff -u libnss-ldap-251/debian/changelog libnss-ldap-251/debian/changelog
--- libnss-ldap-251/debian/changelog
+++ libnss-ldap-251/debian/changelog
@@ -1,3 +1,11 @@
+libnss-ldap (251-7.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Fix a double-free in _nss_ldap_ent_context_init_locked() when we
+ have an existing query to dispose of. Potentially closes: #366172.
+
+ -- Steve Langasek <[EMAIL PROTECTED]> Mon, 13 Nov 2006 15:14:46 -0800
+
libnss-ldap (251-7) unstable; urgency=low
* Meh, correctly include escape-fixing NMU
