Bug 699686

+++ 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 on 2011-04-13 17:56:23 GMT ---

Created attachment 491842 [details]
File: backtrace

--- Additional comment from ppisar 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 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 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.