pop3-login core dump when using TLSSTART on version dovecot-2.2.32 (INTERNAL)

[Arvid.Eikas at telenor.com]

Hi,

Here is the gdb output.

Arvid

GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-94.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /local/misc/mail/dovecot-32/libexec/dovecot/pop3-login...done.
[New LWP 15894]
Core was generated by `dovecot-test/pop3-login'.
Program terminated with signal 6, Aborted.
#0  0x00007ff0bd9cf1d7 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.17-157.el7_3.1.x86_64
(gdb) bt full
#0  0x00007ff0bd9cf1d7 in raise () from /lib64/libc.so.6
No symbol table info available.
#1  0x00007ff0bd9d08c8 in abort () from /lib64/libc.so.6
No symbol table info available.
#2  0x00007ff0bd3c0f2f in engine_unlocked_finish (e=0x1c51c60, unlock_for_handlers=1) at eng_init.c:115
        to_return = 1
#3  0x00007ff0bd3c1064 in ENGINE_finish (e=0x1c51c60) at eng_init.c:150
        to_return = 1
#4  0x00007ff0be0f9300 in ssl_proxy_deinit () from /local/nextmail/dovecot/lib64/dovecot/libdovecot-login.so.0
No symbol table info available.
#5  0x00007ff0be0f4472 in main_deinit () from /local/nextmail/dovecot/lib64/dovecot/libdovecot-login.so.0
No symbol table info available.
#6  0x00007ff0be0f479f in login_binary_run () from /local/nextmail/dovecot/lib64/dovecot/libdovecot-login.so.0
No symbol table info available.
#7  0x00000000004032da in main (argc=1, argv=0x7ffe3059f3f8) at client.c:356
No locals.



-----Original Message-----
From: Aki Tuomi [mailto:aki.tuomi at dovecot.fi] 
Sent: 8. september 2017 14:08
To: Eikås Arvid; dovecot at dovecot.org
Subject: Re: pop3-login core dump when using TLSSTART on version dovecot-2.2.32 (OPEN)

I assume you mean STARTTLS. Can you provide gdb /path/to/bin /path/to/core and provide output of bt full?

Aki


On 08.09.2017 15:01, Arvid.Eikas at telenor.com wrote:
> Hi,
>
> Pop3-login are CORE-dumping when I log on with TLSSTART, I believe the same will happen with imap-logon to, but I have not tested it yet.
> The TLS session is coming up and it works fine until I log off, then it's core dump.  Open sslvesrion is   openssl-1.0.2k.
> We ran dovecot-2.2.27 before we upgraded to dovecote-2.2.32, and that 
> seems to work fine. (not core dumping)
>
>
> Arvid
>
>
> LOG
> Sep 05 14:27:34 pop3-login: Debug: SSL: elliptic curve secp384r1 will 
> be used for ECDH and ECDHE key exchanges Sep 05 14:30:30 pop3-login: 
> Debug: SSL: elliptic curve secp384r1 will be used for ECDH and ECDHE 
> key exchanges Sep 05 14:30:30 pop3-login: Debug: SSL: elliptic curve 
> secp384r1 will be used for ECDH and ECDHE key exchanges Sep 05 
> 14:30:42 pop3-login: Debug: SSL: elliptic curve secp384r1 will be used 
> for ECDH and ECDHE key exchanges Sep 05 14:30:42 pop3-login: Debug: 
> SSL: elliptic curve secp384r1 will be used for ECDH and ECDHE key 
> exchanges Sep 05 14:30:50 pop3-login: Info: Login: user=<tstrand>, 
> method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=18361, secured, 
> session=<65m8ZXBYtpN/AAAB> Sep 05 14:30:50 pop3-login: Error: 
> ENGINE_finish, bad functional reference count Sep 05 14:30:50 
> pop3-login: Fatal: master: service(pop3-login): child 18359 killed 
> with signal 6 (core dumped)
>
>
>
>
>
>
> From  ./crypto/engine/eng_init.c
>
> .........
> int engine_unlocked_finish(ENGINE *e, int unlock_for_handlers) {
>     int to_return = 1;
>
>     /*
>      * Reduce the functional reference count here so if it's the terminating
>      * case, we can release the lock safely and call the finish() handler
>      * without risk of a race. We get a race if we leave the count until
>      * after and something else is calling "finish" at the same time -
>      * there's a chance that both threads will together take the count from 2
>      * to 0 without either calling finish().
>      */
>     e->funct_ref--;
>     engine_ref_debug(e, 1, -1);
>     if ((e->funct_ref == 0) && e->finish) {
>         if (unlock_for_handlers)
>             CRYPTO_w_unlock(CRYPTO_LOCK_ENGINE);
>         to_return = e->finish(e);
>         if (unlock_for_handlers)
>             CRYPTO_w_lock(CRYPTO_LOCK_ENGINE);
>         if (!to_return)
>             return 0;
>     }
> #ifdef REF_CHECK
>     if (e->funct_ref < 0) {
>         fprintf(stderr, "ENGINE_finish, bad functional reference count\n");
>         abort();
>
> .........
>
> /* The API (locked) version of "finish" */ int ENGINE_finish(ENGINE 
> *e) {
>     int to_return = 1;
>
>     if (e == NULL) {
>         ENGINEerr(ENGINE_F_ENGINE_FINISH, ERR_R_PASSED_NULL_PARAMETER);
>         return 0;
>     }
>     CRYPTO_w_lock(CRYPTO_LOCK_ENGINE);
>     to_return = engine_unlocked_finish(e, 1);
>     CRYPTO_w_unlock(CRYPTO_LOCK_ENGINE);
>     if (!to_return) {
>         ENGINEerr(ENGINE_F_ENGINE_FINISH, ENGINE_R_FINISH_FAILED);
>         return 0;
>     }
>     return to_return;
> }