Bug 241638
| Summary: | Mutt crash when displaying a message | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Jan "Yenya" Kasprzak <kas> | ||||||
| Component: | mutt | Assignee: | Miroslav Lichvar <mlichvar> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||||
| Severity: | low | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 4.5 | ||||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2010-03-08 09:00:53 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
Created attachment 155578 [details]
A message which crashes mutt
Created attachment 155582 [details]
diff of handler.c between 1.4.1 and 1.4.2.2
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 "?". 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. |
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): mutt-1.4.1-12.el4.x86_64 How reproducible: 100% Steps to Reproduce: 1. save the attached message as /tmp/mailbox 2. run mutt -f /tmp/mailbox 3. try to display the message contents Actual results: mutt crashes with SIGSEGV Expected results: mutt should display the message Additional info: 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[1]); (gdb) where #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. ) at handler.c:1728 #2 0x0000000000424595 in mutt_body_handler (b=0x752150, s=0x7fbfffdec0) at handler.c:1897 #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. ) at copy.c:603 #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-1.4.2.2-5.fc6 does not have this problem (both i386 and x86_64).