Re: [Mutt] #3041: imap fetch segfault
#3041: imap fetch segfault
---------------------+------------------------------------------------------
Reporter: chrisl | Owner: brendan
Type: defect | Status: closed
Priority: major | Milestone: 1.6
Component: IMAP | Version:
Resolution: fixed | Keywords: duplicate 2902
---------------------+------------------------------------------------------
Changes (by brendan):
* status: started => closed
* resolution: => fixed
Old description:
> Hello,
>
> I am getting random segment fault during imap fetching from the outlook
> server.
>
> I take a look at the the core dump.
> {{{
> Program terminated with signal 11, Segmentation fault.
> #0 0x00000000004a3a3f in imap_cmd_step (idata=0x7c31a0) at command.c:558
> 558 if (h && h->active && h->index+1 == msgno)
> (gdb) bt
> #0 0x00000000004a3a3f in imap_cmd_step (idata=0x7c31a0) at command.c:558
> #1 0x00000000004a9c50 in imap_read_headers (idata=0x7c31a0,
> msgbegin=0, msgend=14320) at message.c:256
> #2 0x000037f000000000 in ?? ()
> #3 0x22205443454c4553 in ?? ()
> #4 0x000022786f626e49 in ?? ()
> #5 0x00007fff64522514 in ?? ()
> #6 0x0000003ed6012c85 in _nc_outch () from /lib64/libtinfo.so.5
> #7 0x0000003b52008deb in check_match.8426 () from /lib64/ld-
> linux-x86-64.so.2
> #8 0x0000003b520091f1 in do_lookup_x () from /lib64/ld-linux-x86-64.so.2
> #9 0x0000003b520093ef in _dl_lookup_symbol_x () from
> /lib64/ld-linux-x86-64.so.2
> #10 0x0000003b520093ef in _dl_lookup_symbol_x () from
> /lib64/ld-linux-x86-64.so.2
> }}}
> While I am reading imap_read_headers(). I have a few questions:
>
> - Where it looks like there is two copy of the header construct code
> looks like copy and paste duplicated?
> Shouldn't it be better have some common share function to read one
> message header.
>
> - This code worries me.
> {{{
> if ((mfhrc = msg_fetch_header (ctx, &h, idata->buf, NULL)) == -1)
> continue;
> ....
>
> idx = h.sid - 1;
> ctx->hdrs[idx] = imap_hcache_get (idata, h.data->uid);
> }}}
> h.sid is fetched from the imap server as the message number.
> This means if the message number has gap, there will be NULL
> pointer in the hdrs[]. If the server is malicious, it can corrupt your
> memory.
>
> I log the socket data and find out the case where it crashed,
> I hide some message header here.
>
> mutt:
> {{{
> a0005 FETCH 1:14320 (UID FLAGS INTERNALDATE RFC822.SIZE
> BODY.PEEK[HEADER.FIELDS (DATE FROM SUBJECT TO CC MESSAGE-ID REFERENCES
> CONTENT-TYPE CONTENT-DESCRIPTION IN-REPLY-TO REPLY-TO LINES LIST-POST
> X-LABEL)])
> }}}
> server:
> {{{
> * 1 FETCH (UID 128801 FLAGS (\Seen) INTERNALDATE " 6-Mar-2008 14:46:41
> -0800" RFC822.SIZE 2452 BODY[HEADER.FIELDS (DATE FROM SUBJECT TO CC
> MESSAGE-ID REFERENCES CONTENT-TYPE CONTENT-DESCRIPTION IN-REPLY-TO
> REPLY-TO LINES LIST-POST X-LABEL)] {302} ...
> * 14124 FETCH (FLAGS (\Seen))
> * 14162 FETCH (FLAGS (\Seen))
> * 14165 FETCH (FLAGS (\Seen))
> * 14168 FETCH (FLAGS (\Seen))
> * 14182 FETCH (FLAGS (\Seen))
> * 14203 FETCH (FLAGS (\Seen))
> * 2 FETCH (UID 207001 FLAGS (\Seen) INTERNALDATE "15-Dec-2007 02:23:29
> -0800" RFC822.SIZE 5563 BODY[HEADER.FIELDS (DATE FROM SUBJECT TO CC
> MESSAGE-ID REFERENCES CONTENT-TYPE CONTENT-DESCRIPTION IN-REPLY-TO
> REPLY-TO LINES LIST-POST X-LABEL)] {619}...
> * 3 FETCH (UID 207001 FLAGS (\Seen) INTERNALDATE "15-Dec-2007 02:23:29
> -0800" RFC822.SIZE 5563 BODY[HEADER.FIELDS (DATE FROM SUBJECT TO CC
> MESSAGE-ID REFERENCES CONTENT-TYPE CONTENT-DESCRIPTION IN-REPLY-TO
> REPLY-TO LINES LIST-POST X-LABEL)] {619}...
> }}}
> So it seems that the server send some out of order update information
> of the message. (14124 etc)
> That messs up the message count and generates some NULL at the tail of
> the ctx->hdrs[].
New description:
Hello,
I am getting random segment fault during imap fetching from the outlook
server.
I take a look at the the core dump.
{{{
Program terminated with signal 11, Segmentation fault.
#0 0x00000000004a3a3f in imap_cmd_step (idata=0x7c31a0) at command.c:558
558 if (h && h->active && h->index+1 == msgno)
(gdb) bt
#0 0x00000000004a3a3f in imap_cmd_step (idata=0x7c31a0) at command.c:558
#1 0x00000000004a9c50 in imap_read_headers (idata=0x7c31a0,
msgbegin=0, msgend=14320) at message.c:256
#2 0x000037f000000000 in ?? ()
#3 0x22205443454c4553 in ?? ()
#4 0x000022786f626e49 in ?? ()
#5 0x00007fff64522514 in ?? ()
#6 0x0000003ed6012c85 in _nc_outch () from /lib64/libtinfo.so.5
#7 0x0000003b52008deb in check_match.8426 () from /lib64/ld-
linux-x86-64.so.2
#8 0x0000003b520091f1 in do_lookup_x () from /lib64/ld-linux-x86-64.so.2
#9 0x0000003b520093ef in _dl_lookup_symbol_x () from
/lib64/ld-linux-x86-64.so.2
#10 0x0000003b520093ef in _dl_lookup_symbol_x () from
/lib64/ld-linux-x86-64.so.2
}}}
While I am reading imap_read_headers(). I have a few questions:
- Where it looks like there is two copy of the header construct code
looks like copy and paste duplicated?
Shouldn't it be better have some common share function to read one
message header.
- This code worries me.
{{{
if ((mfhrc = msg_fetch_header (ctx, &h, idata->buf, NULL)) == -1)
continue;
....
idx = h.sid - 1;
ctx->hdrs[idx] = imap_hcache_get (idata, h.data->uid);
}}}
h.sid is fetched from the imap server as the message number.
This means if the message number has gap, there will be NULL
pointer in the hdrs[]. If the server is malicious, it can corrupt your
memory.
I log the socket data and find out the case where it crashed,
I hide some message header here.
mutt:
{{{
a0005 FETCH 1:14320 (UID FLAGS INTERNALDATE RFC822.SIZE
BODY.PEEK[HEADER.FIELDS (DATE FROM SUBJECT TO CC MESSAGE-ID REFERENCES
CONTENT-TYPE CONTENT-DESCRIPTION IN-REPLY-TO REPLY-TO LINES LIST-POST
X-LABEL)])
}}}
server:
{{{
* 1 FETCH (UID 128801 FLAGS (\Seen) INTERNALDATE " 6-Mar-2008 14:46:41
-0800" RFC822.SIZE 2452 BODY[HEADER.FIELDS (DATE FROM SUBJECT TO CC
MESSAGE-ID REFERENCES CONTENT-TYPE CONTENT-DESCRIPTION IN-REPLY-TO
REPLY-TO LINES LIST-POST X-LABEL)] {302} ...
* 14124 FETCH (FLAGS (\Seen))
* 14162 FETCH (FLAGS (\Seen))
* 14165 FETCH (FLAGS (\Seen))
* 14168 FETCH (FLAGS (\Seen))
* 14182 FETCH (FLAGS (\Seen))
* 14203 FETCH (FLAGS (\Seen))
* 2 FETCH (UID 207001 FLAGS (\Seen) INTERNALDATE "15-Dec-2007 02:23:29
-0800" RFC822.SIZE 5563 BODY[HEADER.FIELDS (DATE FROM SUBJECT TO CC
MESSAGE-ID REFERENCES CONTENT-TYPE CONTENT-DESCRIPTION IN-REPLY-TO
REPLY-TO LINES LIST-POST X-LABEL)] {619}...
* 3 FETCH (UID 207001 FLAGS (\Seen) INTERNALDATE "15-Dec-2007 02:23:29
-0800" RFC822.SIZE 5563 BODY[HEADER.FIELDS (DATE FROM SUBJECT TO CC
MESSAGE-ID REFERENCES CONTENT-TYPE CONTENT-DESCRIPTION IN-REPLY-TO
REPLY-TO LINES LIST-POST X-LABEL)] {619}...
}}}
So it seems that the server send some out of order update information
of the message. (14124 etc)
That messs up the message count and generates some NULL at the tail of
the ctx->hdrs[].
--
Comment:
No response; I believe it is fixed.
--
Ticket URL: <http://dev.mutt.org/trac/ticket/3041#comment:>
Mutt <http://www.mutt.org/>
The Mutt mail user agent