Bug 128364

Created attachment 102129 [details]
Output/configuration as described in bug report

This does appear to be TLS related. When used without TLS (port 389,
start_tls=no,tls_mode=no), it works perfectly. When TLS is used (port
636, start_tls=no,tls_mode=no), it seg faults.

I just tried it on a RHEL3ES machine with all available patch/updates
installed, and did a "rpmbuild -ba" on the just released FreeRadius
1.0.0, and then installed and configured it, with a result just as
before (which, as I said, I got with the original RHEL3 version of
FreeRadius plus its later official update). An extract of running
radiusd with the -X flag (and ldap_debug=1) is shown below:

Ready to process requests.
rad_recv: Access-Request packet from host 10.20.9.1:16606, id=22,
length=48
        User-Name = "<removed>"
        User-Password = "<removed>"
  Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 0
  modcall[authorize]: module "preprocess" returns ok for request 0
  modcall[authorize]: module "chap" returns noop for request 0
  modcall[authorize]: module "mschap" returns noop for request 0
    rlm_realm: No '@' in User-Name = "<removed>", looking up realm NULL
    rlm_realm: Found realm "NULL"
    rlm_realm: Adding Stripped-User-Name = "<removed>"
    rlm_realm: Proxying request from user <removed> to realm NULL
    rlm_realm: Adding Realm = "NULL"
    rlm_realm: Authentication realm is LOCAL.
  modcall[authorize]: module "suffix" returns noop for request 0
  rlm_eap: No EAP-Message, not doing EAP
  modcall[authorize]: module "eap" returns noop for request 0
    users: Matched DEFAULT at 10
rlm_ldap: Entering ldap_groupcmp()
radius_xlat:  'dc=dimmy,dc=someplace,dc=com'
radius_xlat:  '(cn=<removed>)'
rlm_ldap: ldap_get_conn: Checking Id: 0
rlm_ldap: ldap_get_conn: Got Id: 0
rlm_ldap: attempting LDAP reconnection
rlm_ldap: (re)connect to ldap2.dimmy.someplace.com:636, authentication 0
rlm_ldap: setting TLS mode to 1
rlm_ldap: setting TLS CACert File to /etc/raddb/certs/demoCA/root.ca.pem
rlm_ldap: bind as <removed>/<removed> to ldap2.dimmy.someplace.com:636
ldap_bind
ldap_simple_bind
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection
ldap_int_open_connection
ldap_connect_to_host: ldap2.dimmy.someplace.com
ldap_new_socket: 6
ldap_prepare_socket: 6
ldap_connect_to_host: Trying 10.14.5.19:636
ldap_connect_timeout: fd: 6 tm: 5 async: 0
ldap_ndelay_on: 6
ldap_is_sock_ready: 6
ldap_ndelay_off: 6
ldap_int_sasl_open: host=ldap2.dimmy.someplace.com
TLS trace: SSL_connect:before/connect initialization
TLS trace: SSL_connect:SSLv2/v3 write client hello A
TLS trace: SSL_connect:SSLv3 read server hello A
TLS certificate verification: depth: 1, subject: <removed>, issuer:
<removed>
TLS certificate verification: depth: 0, subject: <removed>, issuer:
<removed>
TLS trace: SSL_connect:SSLv3 read server certificate A
TLS trace: SSL_connect:SSLv3 read server certificate request A
TLS trace: SSL_connect:SSLv3 read server done A
TLS trace: SSL_connect:SSLv3 write client certificate A
TLS trace: SSL_connect:SSLv3 write client key exchange A
TLS trace: SSL_connect:SSLv3 write change cipher spec A
TLS trace: SSL_connect:SSLv3 write finished A
TLS trace: SSL_connect:SSLv3 flush data
TLS trace: SSL_connect:SSLv3 read finished A
Segmentation fault

I determined that the problem is at the the line 845 in tls.c within
the OpenLDAP library libldap. The line is "method->ext_free(alt);".
From OpenLDAP problem 1924
(http://www.openldap.org/its/index.cgi/Software%20Bugs?id=1924;selectid=1924),
I could see why the problem happens. I have added my comments to a
related issue - bug 111492.

*** This bug has been marked as a duplicate of 111492 ***

Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.