XPDF 4.04 is vulnerable to Null Pointer Dereference in FoFiType1C.cc:2393.

Out-of-bounds array write in Xpdf 4.05 and earlier, triggered by an invalid VerticesPerRow value in a PDF shading dictionary.

Buffer Overflow vulnerability in pdfimages in xpdf 4.03 allows attackers to crash the application via crafted command.

Stack overflow vulnerability in function gmalloc in goo/gmem.cc in xpdf 4.04, allows local attackers to cause a denial of service.

Stack overflow vulnerability in function Dict::find in xpdf/Dict.cc in xpdf 4.04, allows local attackers to cause a denial of service.

In Xpdf 4.05 (and earlier), a PDF object loop in an object stream leads to infinite recursion and a stack overflow.

In Xpdf 4.05 (and earlier), a PDF object loop in the attachments leads to infinite recursion and a stack overflow.

Out-of-bounds array write in Xpdf 4.05 and earlier, triggered by long Unicode sequence in ActualText.

Out-of-bounds array write in Xpdf 4.05 and earlier, triggered by negative object number in indirect reference in the input PDF file.

In Xpdf 4.04 (and earlier), a PDF object loop in the page label tree leads to infinite recursion and a stack overflow.

In Xpdf 4.04 (and earlier), a bad color space object in the input PDF file can cause a divide-by-zero.

In Xpdf 4.04 (and earlier), a PDF object loop in the embedded file tree leads to infinite recursion and a stack overflow.

There is an invalid memory access in the function GfxIndexedColorSpace::mapColorToBase() located in GfxState.cc in Xpdf 4.0.0, as used in pdfalto 0.2. It can be triggered by (for example) sending a crafted pdf file to the pdftops binary. It allows an attacker to cause Denial of Service (Segmentation fault) or possibly have unspecified other impact.

There is an invalid memory access vulnerability in the function TextPage::findGaps() located at TextOutputDev.c in Xpdf 4.01, which can (for example) be triggered by sending a crafted pdf file to the pdftops binary. It allows an attacker to cause Denial of Service (Segmentation fault) or possibly have unspecified other impact.

An infinite recursion in Catalog::findDestInTree can cause denial of service for xpdf 4.02.

An issue was discovered in Xpdf 4.00. XRef::readXRefStream in XRef.cc allows attackers to launch a denial of service (Integer Overflow) via a crafted /Size value in a pdf file, as demonstrated by pdftohtml. This is mainly caused by the program attempting a malloc operation for a large amount of memory.

An issue was discovered in Xpdf 4.00. catalog->getNumPages() in AcroForm.cc allows attackers to launch a denial of service (hang caused by large loop) via a specific pdf file, as demonstrated by pdftohtml. This is mainly caused by a large number after the /Count field in the file.

The DCTStream::readHuffSym function in Stream.cc in the DCT decoder in xpdf before 4.00 allows remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact via crafted JPEG data.

In Xpdf 4.05 (and earlier), very large coordinates in a page box can cause an integer overflow and divide-by-zero.

In Xpdf 4.05 (and earlier), a PDF object loop in a pattern resource leads to infinite recursion and a stack overflow.

SuSE reported a buffer overflow in FoFiType1::parse affecting older xpdf versions. Code snippets from fofi/FoFiType1.cc:

133 void FoFiType1::parse() { ... 163 line = getNextLine(line); 164 for (j = 0; j < 300 && line; ++j) { 165 line1 = getNextLine(line); 166 if ((n = line1 - line) > 255) { 167 n = 255; 168 } 169 strncpy(buf, line, n);

getNextLine can, however, return NULL:

117 char FoFiType1::getNextLine(char line) { 118 while (line < (char )file + len && line != '\x0a' && line != '\x0d') { 119 ++line; 120 } 121 if (line < (char )file + len && line == '\x0d') { 122 ++line; 123 } 124 if (line < (char )file + len && line == '\x0a') { 125 ++line; 126 } 127 if (line >= (char )file + len) { 128 return NULL; 129 }

Therefore, (line1 - line) is not defined / results in negative value n. That value is later passed to strncpy, causing overflow of buf buffer.

Integer overflow in the PSOutputDev::doImageL1Sep function in Xpdf before 3.02pl4, and Poppler 0.x, as used in kdegraphics KPDF, might allow remote attackers to execute arbitrary code via a crafted PDF document that triggers a heap-based buffer overflow.

An integer overflow flaw exists in xpdf's ImageStream::ImageStream (Stream.cc) when calculating size of the imgLine buffer:

320 nVals = width nComps; 321 if (nBits == 1) { 322 imgLineSize = (nVals + 7) & ~7; 323 } else { 324 imgLineSize = nVals; 325 } 326 imgLine = (Guchar )gmallocn(imgLineSize, sizeof(Guchar));

width and nComps used go compute nVals value come from the input PDF file. Their multiplication may overflow / wrap, resulting in smaller imgLine buffer allocation than expected.

ImageStream always uses nVals as an upper bound when writing data into imgLine. Therefore, no buffer overflow occurs in ImageStream, but NULL pointer dereference may occur (gmallocn returns NULL when called with imgLineSize 0).

Pointer to imgLine is also returned out of ImageStream class instance from ImageStream::getLine() method. Callers of the method may later over-read allocated buffer, but no caller over-writing it was identified.

This code was introduced in xpdf in some early versions (exists in 0.9x), so is likely to appear in all applications embedding / forking xpdf.

Integer overflow in the SplashBitmap::SplashBitmap function in Xpdf 3.x before 3.02pl4 and Poppler before 0.12.1 might allow remote attackers to execute arbitrary code via a crafted PDF document that triggers a heap-based buffer overflow. NOTE: some of these details are obtained from third party information. NOTE: this issue reportedly exists because of an incomplete fix for CVE-2009-1188.

Integer overflow in the ObjectStream::ObjectStream function in XRef.cc in Xpdf 3.x before 3.02pl4 and Poppler before 0.12.1, as used in GPdf, kdegraphics KPDF, CUPS pdftops, and teTeX, might allow remote attackers to execute arbitrary code via a crafted PDF document that triggers a heap-based buffer overflow.

Adam Zabrocki reported flaws in xpdf's Splash::drawImage function related to buffer memory allocations:

2220 // allocate pixel buffers 2221 colorBuf = (SplashColorPtr)gmalloc((yp + 1) w nComps); 2222 if (srcAlpha) { 2223 alphaBuf = (Guchar )gmalloc((yp + 1) w); 2224 } else { 2225 alphaBuf = NULL; 2226 }

Values used to compute argument passed to gmalloc come from input PDF file. Properly chosen values will cause gmalloc to return NULL or buffer of insufficient size, leading to NULL pointer dereference or heap buffer overflow later.

Affected Splash output device is not available in xpdf 2.x versions and earlier. It is also not used in xpdf embedded in CUPS or tetex.

This was already fixed in poppler as part of preventive gmalloc -> gmallocn changes: http://cgit.freedesktop.org/poppler/poppler/commit/?id=9cf2325fb2

This fix is also present in the EL5 poppler packages.

Acknowledgements:

Red Hat would like to thank Adam Zabrocki for reporting this issue.

Multiple NULL derefernce flaws were found in xpdf's JBIG2 decoder. A carefully crafted PDF file could cause xpdf to crash when opened.

Will Dormann of the CERT/CC created the extensive testsuite for the JBIG2 decoder in various PDF libraries that found this flaw.

Acknowledgements:

Red Hat would like to thank Will Dormann of the CERT/CC for responsibly reporting these flaws.

An integer overflow flaw was found in xpdf's JBIG2 decoder. This flaw could result in arbitrary code execute with the permissions of the user running xpdf.

Will Dormann of the CERT/CC created the extensive testsuite for the JBIG2 decoder in various PDF libraries that found this flaw.

Acknowledgements:

Red Hat would like to thank Will Dormann of the CERT/CC for responsibly reporting this flaw.

Multiple buffer overflow flaws were found in xpdf's JBIG2 MMR decoder. A carefully crafted PDF file could result in arbitrary code execute with the permissions of the user running xpdf.

Will Dormann of the CERT/CC created the extensive testsuite for the JBIG2 decoder in various PDF libraries that found this flaw.

Acknowledgements:

Red Hat would like to thank Will Dormann of the CERT/CC for responsibly reporting these flaws.

An infinite loop flaw was found in xpdf's JBIG2 MMR decoder. If a carefully crafted PDF file is opened, it could cause xpdf to stop responding.

Will Dormann of the CERT/CC created the extensive testsuite for the JBIG2 decoder in various PDF libraries that found this flaw.

Acknowledgements:

Red Hat would like to thank Will Dormann of the CERT/CC for responsibly reporting this flaw.