Segmentation fault with malformed pdf in xpdf-3.02.4p1 patch. Reposted so
that patch is included inline as I see the standard method is.
$OpenBSD: patch-xpdf_Parser_cc, v 1.0 2010/06/30 $
* Fixes a segmentation fault that occurs when a pdf object's length is
derived from an indirect reference that refers to itself.
--- xpdf/Parser.cc.orig Tue Feb 27 16:05:52 2007
+++ xpdf/Parser.cc Wed Jun 30 13:19:12 2010
@@ -106,12 +106,15 @@ Object *Parser::getObj(Object *obj, Guchar *fileKey,
} else if (buf1.isInt()) {
num = buf1.getInt();
shift();
- if (buf1.isInt() && buf2.isCmd("R")) {
+ if (buf1.isInt() && buf2.isCmd("R") && (num != objNum))
{
obj->initRef(num, buf1.getInt());
shift();
shift();
- } else {
- obj->initInt(num);
+ } else if (buf1.isInt() && buf2.isCmd("R") && (num == objNum)) {
+
obj->free();
+
obj->initError();
+ } else
{
+
obj->initInt(num);
}
// string
On Wed, Jun 30, 2010 at 2:33 PM, Grant Friday <[email protected]> wrote:
> Hey ports@
>
> I apologize if this is the incorrect place to send this message as I wasn't
> sure who the maintainer was. I found a bug that crashes xpdf-3.02.4p1 and
> wrote a patch for it. This crash happens when a pdf file has an object
> whose length is derived from an indirect object reference but instead the
> reference points to the original object itself. I provided an example below
> and attached the patch to this message.
>
> Regards,
>
> Grant Friday
>
> Example:
>
> Normal:
> 2 0 obj
> <</Length 3 0 R>>
> stream
> "data here"
> endstream
>
> Crash:
> 2 0 obj
> <</Length 2 0 R>>
> stream
> "data here"
> endstream
>
> Indirect Object:
> 3 0 obj
> "integer size here"
> endobj
>
