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

[Aki Tuomi]

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;
> }