Re: SEGFAULT in opendkim

From: Murray S. Kucherawy <>
Date: Thu, 17 Jan 2013 12:57:17 -0800 (PST)

On Thu, 17 Jan 2013, Christian R??ner wrote:
> installed opendkim-2.7.4 on Gentoo. Service starts and works, but if stopping the service, it seg faults.
> #0 0x000075e1b0a77394 in pthread_mutex_lock () from /lib64/
> #1 0x0000071a00a5c9e0 in dkimf_crypto_lock_callback (mode=<optimized out>, idx=<optimized out>, file=<optimized out>,
> line=<optimized out>) at opendkim-crypto.c:160
> #2 0x000075e1b0dccbc7 in CRYPTO_add_lock () from /usr/lib64/
> #3 0x000075e1b10815c0 in SSL_CTX_free () from /usr/lib64/
> #4 0x000075e1b1d146b6 in ldap_int_tls_destroy (lo=0x75e1b1f2c060 <ldap_int_global_options>) at tls2.c:101
> #5 0x000075e1b2e2fa7c in ?? () from /lib64/
> #6 0x000075e1b06fa5d1 in ?? () from /lib64/
> #7 0x000075e1b06fa625 in exit () from /lib64/
> #8 0x000075e1b06e4494 in __libc_start_main () from /lib64/
> #9 0x0000071a00a470d1 in _start ()
> Because running under a grsec kernel, the whole process gets blocked for
> 15 minutes (bruteforce prevention) and it kills all instances of
> opendkim (I have 2, one for signing, one for verifying)
> I compiled opendkim, cyrus-sasl and openldap with -ggdb3

This is a known problem for installations that use openldap with opendkim.
openldap goes through some steps to ensure that libcrypto is set up with
mutexes as openssl requires, but opendkim does the same set of steps;
during shutdown, both of them call the opposite routine to free those
resources but that results in a double-free and/or heap corruption, and
you get this crash.

I contend that openldap shouldn't be doing this; libraries shouldn't be
initializing each other, as that's the job of the application. But
understanding that openldap is probably not as agile as we are and may
disagree, opendkim 2.8.0 includes the option to skip the libcrypto setup
steps in order to avoid this problem.

I will be starting 2.8.0 betas soon, so you can give this option a try in
the near future.

Received on Thu Jan 17 2013 - 20:57:34 PST

This archive was generated by hypermail 2.3.0 : Thu Jan 17 2013 - 21:00:02 PST