Bug 699686 - [abrt] libpst-0.6.49-1.fc14.1: pst_base64_encode_multiple: Process /usr/bin/readpst was killed by signal 11 (SIGSEGV)
[abrt] libpst-0.6.49-1.fc14.1: pst_base64_encode_multiple: Process /usr/bin/r...
Status: CLOSED NEXTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libpst (Show other bugs)
6.1
x86_64 Unspecified
low Severity medium
: rc
: ---
Assigned To: Petr Pisar
Desktop QE
abrt_hash:97f1a0a0fcc86107080b81a1ff8...
: Patch
Depends On:
Blocks: 836160 1355984
  Show dependency treegraph
 
Reported: 2011-04-26 07:16 EDT by Petr Pisar
Modified: 2016-08-31 08:17 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 696263
Environment:
Last Closed: 2016-08-31 08:17:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Fix back-ported from 0.6.51 (5.04 KB, patch)
2011-04-26 07:21 EDT, Petr Pisar
no flags Details | Diff

  None (edit)
Description Petr Pisar 2011-04-26 07:16:29 EDT
+++ This bug was initially created as a clone of Bug #696263 +++

abrt version: 1.1.17
architecture: x86_64
Attached file: backtrace, 18896 bytes
cmdline: readpst -D Outlook.pst
component: libpst
Attached file: coredump, 15335424 bytes
crash_function: pst_base64_encode_multiple
executable: /usr/bin/readpst
kernel: 2.6.35.12-88.fc14.x86_64
package: libpst-0.6.49-1.fc14.1
rating: 4
reason: Process /usr/bin/readpst was killed by signal 11 (SIGSEGV)
release: Fedora release 14 (Laughlin)
time: 1302717127
uid: 500

How to reproduce
-----
1. Attempt to extract the PST file to mbox with readpst
2. Crash reported and readpst hangs.
3.

--- Additional comment from justin@onitato.com on 2011-04-13 17:56:23 GMT ---

Created attachment 491842 [details]
File: backtrace

--- Additional comment from ppisar@redhat.com on 2011-04-14 16:22:16 GMT ---

The crash was here:

char *pst_base64_encode_multiple(void *data, size_t size, int *line_count)
{
    char *output;
    char *ou;
    unsigned char *p   = (unsigned char *)data;
    unsigned char *dte = p + size;

    if (data == NULL || size == 0) return NULL;

    ou = output = (char *)malloc(size / 3 * 4 + (size / 57) + 6);
    if (!output) return NULL;

    while((dte-p) >= 3) {
        unsigned char x = p[0];
→       unsigned char y = p[1];
        unsigned char z = p[2];
        base64_append(&ou, line_count, base64_code_chars[ x >> 2 ]);
        base64_append(&ou, line_count, base64_code_chars[ ((x & 0x03) << 4) | (y >> 4) ]);
        base64_append(&ou, line_count, base64_code_chars[ ((y & 0x0F) << 2) | (z >> 6) ]);
        base64_append(&ou, line_count, base64_code_chars[ z & 0x3F ]);
        p+=3;
    };
[...]

while dereferencing p[1]. The reported `size' (1609013) of `data' array does not match allocated memory and causes segmentation fault. Because p[0] is '\0' I guess the size has been determined as end of string without respecting the input is binary stream.

Unfortunately the size (attach->data.size) is computed somewhere else and the stack dump does not provide enough details to find the bug.

[...]

--- Additional comment from ppisar@redhat.com on 2011-04-19 12:19:12 GMT ---

There is lot of:

==13827== Invalid read of size 1
==13827==    at 0x4C3D516: pst_base64_encode_multiple (libstrfunc.c:50)
==13827==    by 0x4C3D407: pst_base64_encode (libstrfunc.c:24)
==13827==    by 0x4C0E97B: pst_attach_to_file_base64 (libpst.c:606)
==13827==    by 0x405375: write_inline_attachment (readpst.c:1068)
==13827==    by 0x4073F6: write_normal_email (readpst.c:1640)
==13827==    by 0x402C6D: process (readpst.c:322)
==13827==    by 0x402920: process (readpst.c:263)
==13827==    by 0x4038DE: main (readpst.c:597)
==13827==  Address 0x877c256 is 0 bytes after a block of size 9,590 alloc'd
==13827==    at 0x4A05E46: malloc (vg_replace_malloc.c:195)
==13827==    by 0x4A05EC0: realloc (vg_replace_malloc.c:476)
==13827==    by 0x4C20661: pst_process (libpst.c:2590)
==13827==    by 0x4C112AD: pst_parse_item (libpst.c:1302)
==13827==    by 0x402787: process (readpst.c:234)
==13827==    by 0x402920: process (readpst.c:263)
==13827==    by 0x4038DE: main (readpst.c:597)

always in pst_base64_encode_multiple() but different lines. Fortunately 17 places only:

==13827== ERROR SUMMARY: 437490 errors from 17 contexts (suppressed: 6 from 6)

(The line numbers correspond to hg tip of libpst).

[...]

--- Additional comment from updates@fedoraproject.org on 2011-04-24 01:49:42 GMT ---

Package libpst-0.6.51-1.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libpst-0.6.51-1.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/libpst-0.6.51-1.fc15
then log in and leave karma (feedback).

-----

This issue has been fixed in upstream 0.6.51 version.
Comment 1 Petr Pisar 2011-04-26 07:21:14 EDT
Created attachment 494878 [details]
Fix back-ported from 0.6.51

This is back-ported patch that should fix this problem.

Please note there is no public test case.
Comment 2 RHEL Product and Program Management 2011-07-05 19:41:40 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

Note You need to log in before you can comment on or make changes to this bug.