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

2017-09-11 Thread Aki Tuomi
Can you outline the exact steps you perform to get this?

Aki

On 11.09.2017 13:42, arvid.ei...@telenor.com wrote:
> Hi,
>
> I switched back to 2.2.27 with the same config that I am using for 2.2.32 and 
> it work fine.  
>
> Sep 11 11:49:37 imap-login: Info: Login: user=, method=PLAIN, 
> rip=88.89.118.45, lip=148.123.160.116, mpid=18709, TLS, 
> session=
> Sep 11 11:49:40 imap(mailuser) Session-ID v7o22OZYrsdYWXYt RemoteIP 
> 88.89.118.45  Maildir /var/nextmail/nfs2.flex14/49/79/841 Info: Logged out 
> in=4518 out=273720 deleted 0 expunged 0 trashed 0
> Sep 11 11:49:40 imap-login: Debug: SSL alert: close notify [88.89.118.45]
>
> How could I proceed?  Any clue?  It is quite annoying to see this entry in 
> the log for each session.
>
> Arvid
>
>
>
>
> -Original Message-
> From: Aki Tuomi [mailto:aki.tu...@dovecot.fi] 
> Sent: 11. september 2017 09:18
> To: Eikås Arvid; dovecot@dovecot.org
> Subject: Re: pop3-login core dump when using TLSSTART on version 
> dovecot-2.2.32 (INTERNAL)
>
> Hi!
>
> I tried to reproduce this problem with dovecot-2.2.32 and OpenSSL 1.0.1k and 
> was not able to. I enabled -DREF_CHECK on OpenSSL, but to no avail, the 
> process did not crash. Is there something else you've done?
>
> Aki
>
>
> On 11.09.2017 08:07, arvid.ei...@telenor.com wrote:
>> 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  0x7ff0bd9cf1d7 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  0x7ff0bd9cf1d7 in raise () from /lib64/libc.so.6 No symbol 
>> table info available.
>> #1  0x7ff0bd9d08c8 in abort () from /lib64/libc.so.6 No symbol 
>> table info available.
>> #2  0x7ff0bd3c0f2f in engine_unlocked_finish (e=0x1c51c60, 
>> unlock_for_handlers=1) at eng_init.c:115
>> to_return = 1
>> #3  0x7ff0bd3c1064 in ENGINE_finish (e=0x1c51c60) at eng_init.c:150
>> to_return = 1
>> #4  0x7ff0be0f9300 in ssl_proxy_deinit () from 
>> /local/nextmail/dovecot/lib64/dovecot/libdovecot-login.so.0
>> No symbol table info available.
>> #5  0x7ff0be0f4472 in main_deinit () from 
>> /local/nextmail/dovecot/lib64/dovecot/libdovecot-login.so.0
>> No symbol table info available.
>> #6  0x7ff0be0f479f in login_binary_run () from 
>> /local/nextmail/dovecot/lib64/dovecot/libdovecot-login.so.0
>> No symbol table info available.
>> #7  0x004032da in main (argc=1, argv=0x7ffe3059f3f8) at 
>> client.c:356 No locals.
>>
>>
>>
>> -Original Message-
>> From: Aki Tuomi [mailto:aki.tu...@dovecot.fi]
>> Sent: 8. september 2017 14:08
>> To: Eikås Arvid; dovecot@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.ei...@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 

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

2017-09-11 Thread Arvid.Eikas
Hi,

I switched back to 2.2.27 with the same config that I am using for 2.2.32 and 
it work fine.  

Sep 11 11:49:37 imap-login: Info: Login: user=, method=PLAIN, 
rip=88.89.118.45, lip=148.123.160.116, mpid=18709, TLS, 
session=
Sep 11 11:49:40 imap(mailuser) Session-ID v7o22OZYrsdYWXYt RemoteIP 
88.89.118.45  Maildir /var/nextmail/nfs2.flex14/49/79/841 Info: Logged out 
in=4518 out=273720 deleted 0 expunged 0 trashed 0
Sep 11 11:49:40 imap-login: Debug: SSL alert: close notify [88.89.118.45]

How could I proceed?  Any clue?  It is quite annoying to see this entry in the 
log for each session.

Arvid




-Original Message-
From: Aki Tuomi [mailto:aki.tu...@dovecot.fi] 
Sent: 11. september 2017 09:18
To: Eikås Arvid; dovecot@dovecot.org
Subject: Re: pop3-login core dump when using TLSSTART on version dovecot-2.2.32 
(INTERNAL)

Hi!

I tried to reproduce this problem with dovecot-2.2.32 and OpenSSL 1.0.1k and 
was not able to. I enabled -DREF_CHECK on OpenSSL, but to no avail, the process 
did not crash. Is there something else you've done?

Aki


On 11.09.2017 08:07, arvid.ei...@telenor.com wrote:
> 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  0x7ff0bd9cf1d7 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  0x7ff0bd9cf1d7 in raise () from /lib64/libc.so.6 No symbol 
> table info available.
> #1  0x7ff0bd9d08c8 in abort () from /lib64/libc.so.6 No symbol 
> table info available.
> #2  0x7ff0bd3c0f2f in engine_unlocked_finish (e=0x1c51c60, 
> unlock_for_handlers=1) at eng_init.c:115
> to_return = 1
> #3  0x7ff0bd3c1064 in ENGINE_finish (e=0x1c51c60) at eng_init.c:150
> to_return = 1
> #4  0x7ff0be0f9300 in ssl_proxy_deinit () from 
> /local/nextmail/dovecot/lib64/dovecot/libdovecot-login.so.0
> No symbol table info available.
> #5  0x7ff0be0f4472 in main_deinit () from 
> /local/nextmail/dovecot/lib64/dovecot/libdovecot-login.so.0
> No symbol table info available.
> #6  0x7ff0be0f479f in login_binary_run () from 
> /local/nextmail/dovecot/lib64/dovecot/libdovecot-login.so.0
> No symbol table info available.
> #7  0x004032da in main (argc=1, argv=0x7ffe3059f3f8) at 
> client.c:356 No locals.
>
>
>
> -Original Message-
> From: Aki Tuomi [mailto:aki.tu...@dovecot.fi]
> Sent: 8. september 2017 14:08
> To: Eikås Arvid; dovecot@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.ei...@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=, 
>> method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=18361, secured, 
>> session=<65m8ZXBYtpN/AAAB> 

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

2017-09-11 Thread Aki Tuomi
Hi!

I tried to reproduce this problem with dovecot-2.2.32 and OpenSSL 1.0.1k
and was not able to. I enabled -DREF_CHECK on OpenSSL, but to no avail,
the process did not crash. Is there something else you've done?

Aki


On 11.09.2017 08:07, arvid.ei...@telenor.com wrote:
> 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 
> 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:
> ...
> 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  0x7ff0bd9cf1d7 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  0x7ff0bd9cf1d7 in raise () from /lib64/libc.so.6
> No symbol table info available.
> #1  0x7ff0bd9d08c8 in abort () from /lib64/libc.so.6
> No symbol table info available.
> #2  0x7ff0bd3c0f2f in engine_unlocked_finish (e=0x1c51c60, 
> unlock_for_handlers=1) at eng_init.c:115
> to_return = 1
> #3  0x7ff0bd3c1064 in ENGINE_finish (e=0x1c51c60) at eng_init.c:150
> to_return = 1
> #4  0x7ff0be0f9300 in ssl_proxy_deinit () from 
> /local/nextmail/dovecot/lib64/dovecot/libdovecot-login.so.0
> No symbol table info available.
> #5  0x7ff0be0f4472 in main_deinit () from 
> /local/nextmail/dovecot/lib64/dovecot/libdovecot-login.so.0
> No symbol table info available.
> #6  0x7ff0be0f479f in login_binary_run () from 
> /local/nextmail/dovecot/lib64/dovecot/libdovecot-login.so.0
> No symbol table info available.
> #7  0x004032da in main (argc=1, argv=0x7ffe3059f3f8) at client.c:356
> No locals.
>
>
>
> -Original Message-
> From: Aki Tuomi [mailto:aki.tu...@dovecot.fi] 
> Sent: 8. september 2017 14:08
> To: Eikås Arvid; dovecot@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.ei...@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=, 
>> 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) 

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

2017-09-10 Thread Arvid.Eikas
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 
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:
...
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  0x7ff0bd9cf1d7 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  0x7ff0bd9cf1d7 in raise () from /lib64/libc.so.6
No symbol table info available.
#1  0x7ff0bd9d08c8 in abort () from /lib64/libc.so.6
No symbol table info available.
#2  0x7ff0bd3c0f2f in engine_unlocked_finish (e=0x1c51c60, 
unlock_for_handlers=1) at eng_init.c:115
to_return = 1
#3  0x7ff0bd3c1064 in ENGINE_finish (e=0x1c51c60) at eng_init.c:150
to_return = 1
#4  0x7ff0be0f9300 in ssl_proxy_deinit () from 
/local/nextmail/dovecot/lib64/dovecot/libdovecot-login.so.0
No symbol table info available.
#5  0x7ff0be0f4472 in main_deinit () from 
/local/nextmail/dovecot/lib64/dovecot/libdovecot-login.so.0
No symbol table info available.
#6  0x7ff0be0f479f in login_binary_run () from 
/local/nextmail/dovecot/lib64/dovecot/libdovecot-login.so.0
No symbol table info available.
#7  0x004032da in main (argc=1, argv=0x7ffe3059f3f8) at client.c:356
No locals.



-Original Message-
From: Aki Tuomi [mailto:aki.tu...@dovecot.fi] 
Sent: 8. september 2017 14:08
To: Eikås Arvid; dovecot@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.ei...@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=, 
> 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);
> CRYPT