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

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

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