dovecot - Oct 2008 - dovecot 1.1.4 maildir imap segfault in message_parse_header_next

I've tried to stress test dovecot 1.1.4 with imaptest for days without
any assertion failure or crash.
Just some "got too little data" messages.

So far it's the most stable 1.1.x version.

Today a user got this imap segfault with vanilla 1.1.4 (I don't know
if it's something you have already fixed in current tree).
The user didn't complain of anything, I've just found the error in the
logs and the core file.

Regards,
Diego.

----
Core was generated by `/usr/libexec/dovecot/imap'.
Program terminated with signal 11, Segmentation fault.
#0  0x080c8d41 in message_parse_header_next (ctx=0x8774fa0,
hdr_r=0xbfa438e0) at message-header-parser.c:114
114                             if (msg[0] == '\n' ||
(gdb) bt full
#0  0x080c8d41 in message_parse_header_next (ctx=0x8774fa0,
hdr_r=0xbfa438e0) at message-header-parser.c:114
        msg = (const unsigned char *) 0x0
        i = <value optimized out>
        size = 0
        startpos = <value optimized out>
        colon_pos = 4294967295
        parse_size = 0
        value_pos = <value optimized out>
        ret = -2
        continued = false
        continues = <value optimized out>
        crlf_newline = false
#1  0x080c62f5 in read_header (mstream=0x877d6d0) at istream-header-filter.c:163
        hdr = (struct message_header_line *) 0x0
        highwater_offset = <value optimized out>
        pos = <value optimized out>
        ret = <value optimized out>
        matched = false
        hdr_ret = <value optimized out>
        __PRETTY_FUNCTION__ = '\0' <repeats 11 times>
#2  0x080c6a17 in i_stream_header_filter_read (stream=0x877d6d0) at
istream-header-filter.c:293
        mstream = (struct header_filter_istream *) 0xfffffffe
        ret = <value optimized out>
        pos = <value optimized out>
#3  0x080d4fa8 in i_stream_read (stream=0x877d6f8) at istream.c:73
        _stream = (struct istream_private *) 0xfffffffe
        ret = <value optimized out>
        __PRETTY_FUNCTION__ = '\0' <repeats 13 times>
#4  0x080d505d in i_stream_read_data (stream=0x877d6f8,
data_r=0xbfa439a8, size_r=0xbfa439a4, threshold=0) at istream.c:299
        ret = 0
        read_more = false
        __PRETTY_FUNCTION__ = '\0' <repeats 18 times>
#5  0x080cb8ec in message_get_body_size (input=0x877d6f8,
body=0xbfa439d8, has_nuls=0x0) at message-size.c:76
        msg = <value optimized out>
        i = <value optimized out>
        size = <value optimized out>
        missing_cr_count = <value optimized out>
        __PRETTY_FUNCTION__ = '\0' <repeats 21 times>
#6  0x08064178 in fetch_body_header_fields (ctx=0x875e668,
mail=0x8776138, body=0x875e958) at imap-fetch-body.c:458
        size = {physical_size = 0, virtual_size = 0, lines = 0}
        old_offset = 0
#7  0x08062218 in imap_fetch (ctx=0x875e668) at imap-fetch.c:309
        _data_stack_cur_id = 4
        ret = <value optimized out>
        __PRETTY_FUNCTION__ =
"\000\000\000\000\000\000\000\000\000\000"
#8  0x0805bd9e in cmd_fetch (cmd=0x875e5c0) at cmd-fetch.c:152
        ctx = (struct imap_fetch_context *) 0x875e668
        args = (const struct imap_arg *) 0x8762638
        search_arg = (struct mail_search_arg *) 0x875e610
        messageset = <value optimized out>
        ret = <value optimized out>
#9  0x0805fe8c in client_command_input (cmd=0x875e5c0) at client.c:580
        client = (struct client *) 0x875e368
        command = <value optimized out>
        __PRETTY_FUNCTION__ = '\0' <repeats 20 times>
#10 0x0805ff35 in client_command_input (cmd=0x875e5c0) at client.c:629
        client = (struct client *) 0x875e368
        command = (struct command *) 0x0
        __PRETTY_FUNCTION__ = '\0' <repeats 20 times>
#11 0x080606f5 in client_handle_input (client=0x875e368) at client.c:670
        _data_stack_cur_id = 3
        ret = <value optimized out>
        remove_io = <value optimized out>
        handled_commands = false
#12 0x0806090e in client_input (client=0x875e368) at client.c:725
        cmd = <value optimized out>
        output = (struct ostream *) 0x875e4ec
        bytes = 197
        __PRETTY_FUNCTION__ = '\0' <repeats 12 times>
#13 0x080d8710 in io_loop_handler_run (ioloop=0x875c9b0) at ioloop-epoll.c:203
        ctx = <value optimized out>
        event = (const struct epoll_event *) 0x875cae8
        list = (struct io_list *) 0x875e568
        io = (struct io_file *) 0x875e548
        tv = {tv_sec = 4, tv_usec = 926334}
        t_id = 2
        msecs = <value optimized out>
        ret = 1
        i = 0
        j = 0
        call = <value optimized out>
#14 0x080d77f8 in io_loop_run (ioloop=0x875c9b0) at ioloop.c:320
No locals.
#15 0x0806848c in main (argc=Cannot access memory at address 0x0
) at main.c:293
No locals.

On Oct 16, 2008, at 11:33 AM, Diego Liziero wrote:
> Today a user got this imap segfault with vanilla 1.1.4 (I don't know
Hmm. And Maildir as topic says?
> #0  0x080c8d41 in message_parse_header_next (ctx=0x8774fa0,
> hdr_r=0xbfa438e0) at message-header-parser.c:114
p *ctx.input
p *ctx.input.real_stream
>        size = 0
i_stream_read_data() returned 0 bytes, but
>        ret = -2
it also returned that the input buffer is full. That shouldn't be  
happening. http://hg.dovecot.org/dovecot-1.1/rev/82d4756f43cc should  
catch it earlier.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20081016/5b682212/attachment-0002.bin>

On Thu, Oct 16, 2008 at 11:39 AM, Timo Sirainen <tss at iki.fi>
wrote:
> On Oct 16, 2008, at 11:33 AM, Diego Liziero wrote:
>
>> Today a user got this imap segfault with vanilla 1.1.4 (I don't
know
>
> Hmm. And Maildir as topic says?
No, sorry, wrong subject, mbox
>> #0  0x080c8d41 in message_parse_header_next (ctx=0x8774fa0,
>> hdr_r=0xbfa438e0) at message-header-parser.c:114
>
> p *ctx.input
> p *ctx.input.real_stream
(gdb)  p *ctx.input
$1 = {v_offset = 0, stream_errno = 0, mmaped = 0, blocking = 1, closed
= 0, seekable = 1, eof = 0, real_stream = 0x8771538}
(gdb) p *ctx.input.real_stream
$2 = {iostream = {refcount = 3, close = 0x80e3f10
<io_stream_default_close_destroy>,
    destroy = 0x80c6d50 <i_stream_header_filter_destroy>,
set_max_buffer_size = 0x80c6d20
<i_stream_header_filter_set_max_buffer_size>,
    destroy_callback = 0x8094630 <index_mail_stream_destroy_callback>,
destroy_context = 0x8776138},
  read = 0x80c6940 <i_stream_header_filter_read>, seek = 0x80c6be0
<i_stream_header_filter_seek>,
  sync = 0x80c5fa0 <i_stream_header_filter_sync>, stat = 0x80c6b40
<i_stream_header_filter_stat>, istream = {v_offset = 0,
    stream_errno = 0, mmaped = 0, blocking = 1, closed = 0, seekable 1, eof = 0,
real_stream = 0x8771538}, fd = -1,
  abs_start_offset = 374333755, statbuf = {st_dev = 0, __pad1 = 0,
__st_ino = 0, st_mode = 0, st_nlink = 0, st_uid = 0, st_gid = 0,
    st_rdev = 0, __pad2 = 0, st_size = -1, st_blksize = 0, st_blocks 0, st_atim
= {tv_sec = 1224104682, tv_nsec = 0}, st_mtim = {
      tv_sec = 1224104682, tv_nsec = 0}, st_ctim = {tv_sec 1224104682, tv_nsec =
0}, st_ino = 0}, buffer = 0x0, w_buffer = 0x0,
  buffer_size = 0, max_buffer_size = 8192, skip = 0, pos = 0, parent 0x8770fe0,
parent_start_offset = 0, line_str = 0x0}
>>       size = 0
>
> i_stream_read_data() returned 0 bytes, but
>
>>       ret = -2
>
> it also returned that the input buffer is full. That shouldn't be
happening.
> http://hg.dovecot.org/dovecot-1.1/rev/82d4756f43cc should catch it earlier.
Ok thanks.