Created attachment 112643 [details]
strace of IPv6 ldapsearch on RHEL3U4

Created attachment 112644 [details]
strace of IPv6 ldapsearch on RHEL4

I guess (without looking at the code) that maybe the sockaddr structures aren't
properly zeroed out when initialized.

Yes, this one:

static int
ldap_pvt_is_socket_ready(LDAP *ld, int s)
...
        /* error slippery */
        struct sockaddr_in sin;
        char ch;
        int dummy = sizeof(sin);
        if ( getpeername( s, (struct sockaddr *) &sin, &dummy )
                == AC_SOCKET_ERROR )
        {
                /* XXX: needs to be replace with ber_stream_read() */
                read(s, &ch, 1);
                TRACE;
                return -1;
        }
        return 0;

No wonder, "sin" is undefined...strange lookups are triggered...strange function
at all...

It isn't because sin is "undefined" (ie, not zeroed), but because it is of
improper type: it should be sockaddr_storage or sockaddr_in6, but not
sockaddr_in - the latter can not be used with IPv6.

BTW: IPv6 enabled postfix (postmap) is segfaulting if system is IPv6 enabled and
openldap is listening on :: or 127.0.0.1 short after the second getpeername call:

cat ldap-test.conf

# LDAP server
#server_host = 127.0.0.1
#server_host = ::ffff:127.0.0.1
server_host = [::1]

# LDAP search base
search_base = dc=domain,dc=example

# LDAP query filter
query_filter = (&(mail=%s)(objectClass=CourierMailAccount))

# LDAP result attribute
result_attribute = uid

# LDAP result filter
result_filter = OK

# Need no bind for upper query
bind = no


# strace postmap -q peter ldap:ldap-test.conf

...
connect(4, {sa_family=AF_INET, sin_port=htons(389),
sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
select(1024, NULL, [4], NULL, {10, 0})  = 1 (out [4], left {10, 0})
getpeername(4, {sa_family=AF_INET, sin_port=htons(389),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
fcntl64(4, F_GETFL)                     = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(4, F_SETFL, O_RDWR)             = 0
getpeername(4, {sa_family=AF_INET, sin_port=htons(389),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++


Note that postfix on my test system is IPv6 enabled but not turned on, therefore
the IPv4 fallback.

But on my real-life system postfix is IPv6 turned on, here postfix segfaults if
 server_host = 127.0.0.1
I can only use
 server_host = [::1]

-> Note here that from remote I can sucessfully connect from an RHEL4 system
(with openldap 2.2)

So I believe if a RHEL3 system is IPv6 enabled and installed LDAP server is
turned on, it can happen that IPv4 connects to LDAP server will cause a segfault.

Note that the strange getpeername occurs 2 times, the first one I am able to fix
with following patch:

--- openldap-2.0.27/libraries/libldap/os-ip.c.orig      2005-04-04
10:18:46.000000000 -0400
+++ openldap-2.0.27/libraries/libldap/os-ip.c   2005-04-04 10:19:05.000000000 -0400
@@ -168,7 +168,7 @@
 #else
 {
        /* error slippery */
-       struct sockaddr_in sin;
+       struct sockaddr_storage sin;
        char ch;
        int dummy = sizeof(sin);
        if ( getpeername( s, (struct sockaddr *) &sin, &dummy )


The second one is in function:

 ldap_host_connected_to
       ...
      struct sockaddr sa;

        if ( getpeername( sd, &sa, &len ) == -1 ) {
                return( NULL );
        }

How to fix this proper for IPv4 and IPv6?

I can't replace it by sockaddr_storage because of a missig member in structure:

libraries/libldap/os-ip.c: In function `ldap_host_connected_to':
libraries/libldap/os-ip.c:464: warning: passing arg 2 of `getpeername' from
incompatible pointer type
libraries/libldap/os-ip.c:475: structure has no member named `sa_family'
libraries/libldap/os-ip.c:521: structure has no member named `sa_family'

Can I use sockaddr_in6, is this IPv4 safe?

Created attachment 112648 [details]
Patch to fix buggy sockaddr usage

Solved 2nd issue by looking into source code of 2.1.30, where fixes already
made. Tststs, looks like 2.0.27 never hit IPv6-ready status, but nobody
warns...

BTW: after installing the fixed library, upper shown postmap execution no
longer segfaults, too.

Created attachment 112657 [details]
Fixed patch

Fixed patch, forgot one minor but important ptr/addr switch

I would only note that I have now installed this on my productive system...

before:
# postmap -q peter ldap:/etc/postfix/ldap-test.cf
Segmentation fault

after:
# postmap -q peter ldap:/etc/postfix/ldap-test.cf
peter

That's ok. Pls. push this fix forward.

Unfortunately, this patch was not included in
https://rhn.redhat.com/errata/RHSA-2005-751.html and therefore 
openldap-2.0.27-20.src.rpm has at least the same segfault bug.

This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
 
For more information of the RHEL errata support policy, please visit:
http://www.redhat.com/security/updates/errata/
 
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.