Bug 696263

Created attachment 491842 [details]
File: backtrace

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.


Justin, can you provide the input Outlook.pst file? (If it does not contain top-secret data, you could encrypt it by my PGP public key and send it to my e-mail address (if small enough) or publish it somewhere to download. You can try to delete messages from the Outlook archive before and leave the problematic one: From <homeinspectorusa> in Inbox. But make sure readpst crashes on it either.)

Your key 7130CC72 expired last month on 3/28/2011. Do you have another one?

The Outlook.pst file is 1.6 GB, but I can upload it to my ftp server, after I encrypt it with your key.

I have new key 67C6FAA2 for some time. Which key server is out of sync?

I found it using 67C6FAA2. I tried searching your email address, and only your old one came up. Odd.

PST - http://dl.dropbox.com/u/13160/Outlook.pst.gpg
MD5 - http://dl.dropbox.com/u/13160/Outlook.pst.gpg.md5

Dropbox is still uploading the PST (about 1GB). I gave you an md5 to checksum the file after you download. Please give it a couple of hours to finish uploading.

It is processing a .pdf file attachment for a message in Personal Folders/Inbox from homeinspectorusa. The size of that .pdf file should be 1609013. Can you process that .pst file with 'readpst -S ...', and does that still segfault, or do you get a 1609013 byte pdf file?

I'm running readpst -S on the file now. Can you tell me the filename of the PDF we are expecting? It hasn't crashed yet, so I'm hopeful.

PST - http://dl.dropbox.com/u/13160/Outlook.pst.gpg
MD5 - http://dl.dropbox.com/u/13160/Outlook.pst.gpg.md5

I've refreshed the PST and MD5. It is encrypted for Carl and Petr. Please give it time to upload. ETA 6 Hours from this post. The MD5 has been provided.

I found the PDF file, I believe.

Lakewalk Circle E, Panama City Beach, Florida 32413   Inspection report FINAL  Wild Heron  2010 CHI.pdf

That's a long file name.

readpst -S seems to have finished successfully. Hopefully, this will help improve readpst :)

Unfortunately, it does not crash on my x86_64 Fedora 14 machine.

The `1300 Lakewalk Circle E, Panama City Beach, Florida 32413   Inspection report FINAL  Wild Heron  2010 CHI Rev _1_.pdf' file is 1608214 bytes long (after conversion and parsed by mutt client). That's less than expected 1609013 and moreover it's in Sent Items and sender differs.

Inbox contains two e-mails with the sender and PDF attachment but all of them have different size: 76117 B and 1008500 B.

Both 1608214 and 76117 are recognized by poppler as damaged (xref table) but both are produced by the same software (Acrobat Distiller 7.0.5 (Windows)).
The 1008500 is valid for poppler and crated by different software (Adobe Photoshop for Windows -- Image Conversion Plug-in). So I cannot say if the output file has been damaged on conversion or it's original file crippled by producer.

I will try to run it under valgrind to find invalid memory accesses. Hope it will help.

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).

I will debug it more later.

I'm installing a rawhide virtual machine to test this build: http://koji.fedoraproject.org/koji/taskinfo?taskID=3008772

per Carl.

Getting a rawhide install seems to be near impossible with the Fedora 15 beta going on. Can I get a 14 package to try?

http://koji.fedoraproject.org/koji/taskinfo?taskID=3016494

F14 scratch build for a proposed fix.

That fixed it for me.

libpst-0.6.51-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/libpst-0.6.51-1.fc14

libpst-0.6.51-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/libpst-0.6.51-1.fc15

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).

libpst-0.6.51-1.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

libpst-0.6.51-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.