[Dovecot] Crash in pop3 with version 2.2.12
Hi,
today I upgraded to version 2.2.12 under Debian Squeeze. I saw some people on the list they had the same problems with version 2.2.11, but which should have been fixed in version 2.2.12.
My logfile shows:
.. Mar 28 08:25:01 mailstore dovecot: pop3-login: Login: user=<ul@domain.net>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=34568, secured, session=<Jp6RmaX1YAB/AAAB> Mar 28 08:25:06 mailstore dovecot: pop3(ul@domain.net pid:34568 session:<Jp6RmaX1YAB/AAAB>): Fatal: master: service(pop3): child 34568 killed with signal 11 (core dumped) ...
I made some more dubugging and I found that the pop3 process crashed on the "uidl" command. Here my output from telnet session:
.. root@mailstore: # telnet localhost 110 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. +OK Dovecot ready. user ul@domain.net +OK pass PASS +OK Logged in. list +OK 5 messages: 1 3492 2 21924 3 3525 4 3472 5 3273 . uidl Connection closed by foreign host. ...
Listing massages or retrieving messages works normally. Only on "uidl" command the services crashes.
I made a backtrace.
-----> start backtrace <----- Core was generated by `dovecot/pop3'. Program terminated with signal 11, Segmentation fault. #0 0x00007f9dd8ca488d in vfprintf () from /lib/libc.so.6 (gdb) bt full #0 0x00007f9dd8ca488d in vfprintf () from /lib/libc.so.6 No symbol table info available. #1 0x00007f9dd8cc6732 in vsnprintf () from /lib/libc.so.6 No symbol table info available. #2 0x00007f9dd904d0db in str_vprintfa (str=0x11aa4f8, fmt=0x409184 "%u %s", args=0x7ffffab4fff0) at str.c:155 args2 = {{gp_offset = 16, fp_offset = 48, overflow_arg_area = 0x7ffffab500e0, reg_save_area = 0x7ffffab50010}} init_size = 4231558 pos = 0 ret = <value optimized out> ret2 = <value optimized out> __FUNCTION__ = "str_vprintfa" #3 0x00000000004055ff in client_send_line (client=0x11d1e50, fmt=<value optimized out>) at pop3-client.c:678 str = 0x11aa4f8 _data_stack_cur_id = 4 va = {{gp_offset = 32, fp_offset = 48, overflow_arg_area = 0x7ffffab500e0, reg_save_area = 0x7ffffab50010}} ret = <value optimized out> __FUNCTION__ = "client_send_line" #4 0x00000000004073cd in list_uidls_saved_iter (client=0x11d1e50, ctx=0x11da3c0) at pop3-commands.c:666 found = true #5 list_uids_iter (client=0x11d1e50, ctx=0x11da3c0) at pop3-commands.c:693 str = <value optimized out> permanent_uidl = <value optimized out> found = <value optimized out> failed = <value optimized out> #6 0x0000000000407d88 in cmd_uidl (client=0x11d1e50, name=<value optimized out>, args=0x408880 "") at pop3-commands.c:874 ctx = 0x0 seq = <value optimized out> #7 client_command_execute (client=0x11d1e50, name=<value optimized out>, args=0x408880 "") at pop3-commands.c:938 No locals. #8 0x0000000000405870 in client_handle_input (client=0x11d1e50) at pop3-client.c:739 _data_stack_cur_id = 3 line = <value optimized out> args = 0x408880 "" ret = <value optimized out> #9 0x00007f9dd903c3d6 in io_loop_call_io (io=0x11d2760) at ioloop.c:388 ioloop = 0x11b2740 t_id = 2 #10 0x00007f9dd903d45f in io_loop_handler_run (ioloop=<value optimized out>) at ioloop-epoll.c:220 ctx = 0x11b2aa0 event = 0x11b3900 list = 0x11b44d0 io = 0x51 tv = {tv_sec = 9, tv_usec = 999326} msecs = <value optimized out> ret = 1 i = 0 call = false __FUNCTION__ = "io_loop_handler_run" #11 0x00007f9dd903c348 in io_loop_run (ioloop=0x11b2740) at ioloop.c:412 __FUNCTION__ = "io_loop_run" #12 0x00007f9dd8fea953 in master_service_run (service=0x11b25d0, callback=0x409186) at master-service.c:566 No locals. #13 0x0000000000404ac7 in main (argc=1, argv=0x11b2390) at main.c:277 set_roots = {0x4094e0, 0x0} login_set = {auth_socket_path = 0x11aa050 "/var/run/dovecot/auth-master", postlogin_socket_path = 0x0, postlogin_timeout_secs = 60, callback = 0x404ca0 <login_client_connected>, failure_callback = 0x404c50 <login_client_failed>, request_auth_token = 0} service_flags = <value optimized out> storage_service_flags = MAIL_STORAGE_SERVICE_FLAG_DISALLOW_ROOT username = 0x0 c = <value optimized out> (gdb) quit -----> end backtrace <-----
And at least my pop3 configuration part:
-----> start config <----- protocol pop3 { mail_plugins = " quota mail_log notify acl zlib stats" pop3_client_workarounds = outlook-no-nuls oe-ns-eoh pop3_lock_session = yes pop3_logout_format = bytes_sent=%o top=%t/%p, retr=%r/%b, del=%d/%m, size=%s uidl_hash=%u session=<%{session}> pop3_reuse_xuidl = yes } -----> end config <-----
Setting "pop3_reuse_xuidl = no" has noe effect. Always the same crash.
Thanks and regards Urban Loesch
Thats my bad. This commit should fix it http://hg.dovecot.org/dovecot-2.2/rev/b0359910ec96. Thanks for reporting it.
Teemu Huovila
Hi,
thanks for your fast help. Now pop3 works again without error.
Thanks Urban
Am 28.03.2014 15:03, schrieb Teemu Huovila:
Thats my bad. This commit should fix it http://hg.dovecot.org/dovecot-2.2/rev/b0359910ec96. Thanks for reporting it.
Teemu Huovila
Le 28 mars 2014 à 17:12, Urban Loesch a écrit :
Hi,
thanks for your fast help. Now pop3 works again without error.
Thanks Urban
Am 28.03.2014 15:03, schrieb Teemu Huovila:
Thats my bad. This commit should fix it http://hg.dovecot.org/dovecot-2.2/rev/b0359910ec96. Thanks for reporting it.
Teemu Huovila
Hello,
I'm still wondering... under which circumstances could the crash occur?
Trying here to reproduce it with an unpatched 2.2.12, without "success": LIST and UIDL always return consistent results, without crashes, and behave that way on several mailboxes.
I'm asking, because the problem could thus be tied to some configurations/settings only (as Urban wrote: "I saw some people on the list [...]"); but the correction brought by b0359910ec96 is an unconditional one.
On the other hand, the problem might be raised because of some particular combination of circumstances, which I can't reproduce now, but which I could face one day or another...
Hence the question: to patch or not to patch?
Many thanks in advance, Axel
On 4/4/2014 11:18 πμ, Axel Luttgens wrote:
I'm still wondering... under which circumstances could the crash occur?
I was wondering the same thing. We are now running 2.2.12 in production for two weeks (unpatched) and we have not seen such an error (despite extensive use of POP3).
Regards, Nick
Hello
On 04/04/2014 11:18 AM, Axel Luttgens wrote:
I'm still wondering... under which circumstances could the crash occur? This issue occurs whenever the function src/pop3/pop3-commands.c:client_uidls_save() is called. The function is called when:
The pop3 internal structure client->message_uidls_save is 1. This in turn happens when any of these is true:
- pop3 logoutformat has %u
- config setting pop3_uidl_duplicates is not the default "allow"
- config setting pop3_save_uidl=yes
The problem manifests in two different ways.
- When the zlib plugin is active the executable crashed due to a segmentation fault.
- If there is no zlib, the data returned by the UIDL command is "off-by-one" and the last data item is null.
Without zlib the error might look something like this: C:uidl S:+OK S:1 00000002533553b6 S:2 00000003533553b6 S:3 00000004533553b6 S:4 00000005533553b6 S:5 00000006533553b6 S:6 (null) S:.
Hence the question: to patch or not to patch? Patch, if your setup will need to meet any of the three criteria triggering the issue, before 2.2.13 is released.
br, Teemu Huovila
Le 4 avr. 2014 à 10:37, Teemu Huovila a écrit :
Hello
On 04/04/2014 11:18 AM, Axel Luttgens wrote:
I'm still wondering... under which circumstances could the crash occur? This issue occurs whenever the function src/pop3/pop3-commands.c:client_uidls_save() is called. The function is called when:
The pop3 internal structure client->message_uidls_save is 1. This in turn happens when any of these is true:
- pop3 logoutformat has %u
- config setting pop3_uidl_duplicates is not the default "allow"
- config setting pop3_save_uidl=yes
The problem manifests in two different ways.
- When the zlib plugin is active the executable crashed due to a segmentation fault.
- If there is no zlib, the data returned by the UIDL command is "off-by-one" and the last data item is null.
Without zlib the error might look something like this: C:uidl S:+OK S:1 00000002533553b6 S:2 00000003533553b6 S:3 00000004533553b6 S:4 00000005533553b6 S:5 00000006533553b6 S:6 (null) S:.
Hence the question: to patch or not to patch? Patch, if your setup will need to meet any of the three criteria triggering the issue, before 2.2.13 is released.
Hello Teemu,
Thank you very much for your kind and very detailed explanation.
None of 1. to 3. apply here, so I guess I've just been lucky. On the other hand, I didn't notice that the patch applies to a very precise context (the client_uidls_save function); it should thus be safe to apply it in all cases (even if un-needed with some *current* configuration).
Sincerely, Axel
participants (4)
-
Axel Luttgens
-
Nikolaos Milas
-
Teemu Huovila
-
Urban Loesch