Red Hat Bugzilla – Bug 241638
Mutt crash when displaying a message
Last modified: 2010-03-08 04:00:53 EST
Description of problem:
Today my mutt crashed with SIGSEGV when trying to view a spam message (I will
attach the message). Because this is segfault on remotely supplied data, this
bug may have security implications.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. save the attached message as /tmp/mailbox
2. run mutt -f /tmp/mailbox
3. try to display the message contents
mutt crashes with SIGSEGV
mutt should display the message
installing a debuginfo package and running mutt under gdb (why does using
debuginfo packages require running as root?) revealed the following backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x0000000000422442 in mutt_decode_base64 (s=0x7fbfffdec0, len=7173, istext=0,
cd=0xffffffffffffffff) at handler.c:308
308 c2 = base64val (buf);
#0 0x0000000000422442 in mutt_decode_base64 (s=0x7fbfffdec0, len=7173,
istext=0, cd=0xffffffffffffffff) at handler.c:308
#1 0x0000000000424381 in mutt_decode_attachment (b=0x752150,
s=dwarf2_read_address: Corrupted DWARF expression.
#2 0x0000000000424595 in mutt_body_handler (b=0x752150, s=0x7fbfffdec0)
#3 0x00000000004132a7 in _mutt_copy_message (fpout=0x7528b0, fpin=0x74fbe0,
hdr=0x751c20, body=0x752150, flags=76, chflags=150) at copy.c:535
#4 0x0000000000413675 in mutt_copy_message (fpout=0x7528b0, src=Variable "src"
is not available.
#5 0x000000000040d5ad in mutt_display_message (cur=0x751c20) at commands.c:142
#6 0x0000000000417691 in mutt_index_menu () at curs_main.c:1070
#7 0x000000000042a86e in main (argc=3, argv=0x7fbffff5d8) at main.c:842
#8 0x00000033e0e1c3fb in __libc_start_main () from /lib64/tls/libc.so.6
#9 0x0000000000405daa in _start ()
#10 0x0000007fbffff5c8 in ?? ()
#11 0x000000000000001c in ?? ()
#12 0x0000000000000003 in ?? ()
#13 0x0000007fbffff84b in ?? ()
#14 0x0000007fbffff859 in ?? ()
#15 0x0000007fbffff85c in ?? ()
#16 0x0000000000000000 in ?? ()
I have also tried to install mutt-1.4.1-12.el4.x86_64.rpm on a FC6/x86_64
system, and the bug can also be reproduced there, while
mutt-1.4.1-12.el4.i386.rpm on a FC6/i386 system works as expected (I have only
one x86_64 RHEL4 system, so I cannot test it on more RHEL systems).
On Fedora systems, mutt-22.214.171.124-5.fc6 does not have this problem (both i386 and
Created attachment 155578 [details]
A message which crashes mutt
Created attachment 155582 [details]
diff of handler.c between 1.4.1 and 126.96.36.199
Looking at the code I have found that in handler.c:mutt_decode_base64()
function the base64val() macro can be called with a negative argument. Before
writing my own fix, I have decided to diff the current (FC6) version of
handler.c to the one in RHEL4, and the only difference is exactly the fix to
this bug. I have applied the attached patch to the mutt-1.4.1-12.el4 src.rpm,
rebuilt it, installed, and it seems the problem is fixed.
As for the Architecture tag of this bug: x86_64 crashes because sizeof(int) <
sizeof(void *), but the bug exists on i386 as well (where the negative index to
an array simply wraps around, so it points to an existing memory).
Thanks for the report.
FC6 package has a patch for this bug, originally reported as bug #166718.
Just an out-of-bound read -- no security impact.
Hmm, could the bug #166718, mentioned in comment #3, be made public?
The tooltip shows that it is "CLOSED RAWHIDE", so there is no need to keep it
private. Also this bug can then be made public, because it is indeed only
read, so no security impact exists.
Jan: right, both bugs are public now.
Thanks. BTW, I think this calls for a policy change in the RH Bugzilla: I
suggest that all closed bugs should be automatically made public (unless
explicitly requested), or something like that (maybe the "private" status should
have an implicit timeout of - say - 1 month, unless explicitly prolonged).
This would have saved me (and you :-) few hours of today's time, because I have
of course tried to search all (public!) mutt bugs in both FC and RHEL before
reporting this bug.
For various reasons like date of security embargo lifted may not be the same as
date of closing the bug we cannot automatically make closed bugs public. In the
concrete bug you mention above the security group should have been removed by
the reporter or package maintainer when the bug was fixed.
OK, maybe the bugzilla should send reminders to security-sensitive-bug owners
asking whether the security embargo is still needed (maybe monthly reminder for
open bugs, bi-weekly one for closed bugs).
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
We are sorry for not addressing this issue in RHEL-4. As mutt is not scheduled for an update in RHEL-4.9, I'm closing this bugzilla as WONTFIX. If you are still experiencing this issue with RHEL-5, please reopen it against RHEL-5.