Xpdf, as used in products such as gpdf, kpdf, pdftohtml, poppler, teTeX, CUPS, libextractor, and others, allows attackers to cause a denial of service (infinite loop) via streams that end prematurely, as demonstrated using the (1) CCITTFaxDecode and (2) DCTDecode streams, aka "Infinite CPU spins."

Integer overflow in the JBIG2 decoder in Xpdf 3.02pl2 and earlier, as used in Poppler and other products, when running on Mac OS X, has unspecified impact, related to "gallocn."

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.

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.

Integer overflow in the createsurfacefromthumbnaildata function in glib/poppler-page.cc in Poppler 0.x allows remote attackers to cause a denial of service (memory corruption) or possibly 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.

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.

A flaw was found in Poppler's Splash backend. A remote attacker could exploit this vulnerability by crafting a malicious PDF file that, when rendered, triggers an integer overflow in the tilingPatternFill function. This overflow leads to an undersized heap memory allocation, allowing a subsequent out-of-bounds write. Successful exploitation could result in arbitrary code execution, information disclosure, or denial of service within the context of the application processing the PDF.

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.

The Page destructor in Page.cc in libpoppler in Poppler 0.8.4 and earlier deletes a pageWidgets object even if it is not initialized by a Page constructor, which allows remote attackers to execute arbitrary code via a crafted PDF document.

Last updated 8 April 2025

AIONLYREPORT package: poppler-26.01.0-7.hum1 ------ Summary: Heap Buffer Overflow in tilingPatternFill via Integer Overflow: unchecked multiplication of tiling pattern dimensions in SplashOutputDev::tilingPatternFill can overflow signed image sizes, leading to an undersized heap allocation and a subsequent out-of-bounds write when a crafted PDF is rendered through Poppler's Splash backend. Requirements to exploit: The attacker must be able to supply a crafted PDF to an application that uses Poppler's Splash backend and cause it to be rendered. No privileges are required, but the malicious file must be opened or otherwise processed through the vulnerable rendering path. Component affected: poppler (Splash backend; poppler/SplashOutputDev.cc::tilingPatternFill / tilingBitmapSrc, with allocation reached through splash/Splash.cc) Version affected: 26.01.0 (confirmed by code inspection); other versions containing the same tilingPatternFill / tilingBitmapSrc logic may also be affected Patch available: no Version fixed (if any already): unknown Upstream coordination: Not yet notified. This report is the initial triage. CVSS: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H - 7.8 (HIGH) AV:L - The attacker supplies a malicious local PDF that must be rendered by a vulnerable application. AC:L - No unusual conditions are required beyond reaching the Splash rendering path with crafted tiling parameters. PR:N - No privileges are required. UI:R - A user or service must open or render the PDF. S:U - Impact remains within the security scope of the vulnerable application process using Poppler. C:H - Successful exploitation could expose data available to the consuming application. I:H - Successful exploitation could allow modification or code execution in the context of the consuming application. A:H - Heap corruption can crash the renderer or otherwise disrupt availability. Impact: Likely Important. This is a heap-based memory-corruption issue in a document-rendering component. Rendering a malicious PDF can corrupt heap memory in the consuming application and may lead to code execution or compromise of confidentiality, integrity, and availability with that application's privileges. User interaction or document processing is required, so this does not rise to Critical. Embargo: yes Reason: This is a likely Important memory-corruption flaw in a widely used PDF rendering library, and no upstream fix is identified in the source report. Public disclosure before remediation would provide actionable exploit detail for malicious-document attacks. Acknowledgement: Aisle Research Steps to reproduce: 1. Build Poppler with AddressSanitizer enabled. 2. Open or render a crafted PDF containing a tiling pattern where (x1 - x0) and/or (y1 - y0) make repeatX / repeatY large enough for surfacewidth repeatX or surfaceheight repeatY to overflow a 32-bit signed int. 3. Trigger the Splash rendering path, for example: pdftoppm -f 1 -singlefile poctilingoverflow.pdf output-prefix 4. Observe AddressSanitizer reporting a heap out-of-bounds write in tilingBitmapSrc during drawImage processing.

Vulnerability Details

resultwidth and resultheight are computed using unchecked signed multiplication and then passed to drawImage(): cpp resultwidth = surfacewidth repeatX; resultheight = surfaceheight repeatY; ... retValue = splash->drawImage(&tilingBitmapSrc, nullptr, &imgData, colorMode, true, resultwidth, resultheight, matc, false, true) == splashOk; However, the source callback still writes based on repeatX and the tile width rather than the possibly overflowed resultwidth: cpp for (int m = 0; m < imgData->repeatX; m++) { for (int x = 0; x < imgData->bitmap->getWidth(); x++) { imgData->bitmap->getPixel(x, imgData->y, q); q += splashColorModeNComps[cMode]; } } drawImage() / scaleImage() allocate line buffers from the supplied width value: cpp lineBuf = (unsigned char )gmallocncheckoverflow(srcWidth, nComps); If surfacewidth repeatX overflows to a small positive value, the allocation becomes too small while tilingBitmapSrc still writes according to the larger repeat count, resulting in heap corruption. Relevant CWE IDs: CWE-190 (Integer Overflow or Wraparound)

CWE-122 / CWE-787 (Heap-based Buffer Overflow / Out-of-bounds Write)

Proposed Fix

Use checked arithmetic before dimension multiplication and avoid signed-overflow expressions in guards: diff diff --git a/poppler/SplashOutputDev.cc b/poppler/SplashOutputDev.cc index XXXXXXX..YYYYYYY 100644 — a/poppler/SplashOutputDev.cc +++ b/poppler/SplashOutputDev.cc @@ -4342,7 +4342,13 @@ bool SplashOutputDev::tilingPatternFill(...) if (surfacewidth == 0 || surfaceheight == 0 || repeatX repeatY <= 4) { + int repeatArea = 0; + if (surfacewidth == 0 || surfaceheight == 0 || + checkedMultiply(repeatX, repeatY, &repeatArea) || + repeatArea <= 4) { state->setCTM(savedCTM[0], savedCTM[1], savedCTM[2], savedCTM[3], savedCTM[4], savedCTM[5]); return false; } @@ -4364,8 +4370,13 @@ bool SplashOutputDev::tilingPatternFill(...)

resultwidth = surfacewidth repeatX;

resultheight = surfaceheight repeatY; + if (checkedMultiply(surfacewidth, repeatX, &resultwidth) || + checkedMultiply(surfaceheight, repeatY, &resultheight) || + resultwidth <= 0 || resultheight <= 0) { + state->setCTM(savedCTM[0], savedCTM[1], savedCTM[2], savedCTM[3], savedCTM[4], savedCTM[5]); + return false; + } + kx = resultwidth / (fabs(kx) + 1); ky = resultheight / (fabs(ky) + 1);

------ This report was generated using AI technology. Always review AI-generated content prior to use

An integer overflow was found in poppler's SplashBitmap::SplashBitmap method. A malicious PDF file could cause poppler to execute with permissions of the user calling the library.

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.

Ludwig Nussel reported an integer overflow in poppler's createsurfacefromthumbnaildata() function. cairopixels buffer is allocated as:

cairopixels = (guchar )gmalloc (4 width height);

http://cgit.freedesktop.org/poppler/poppler/tree/glib/poppler-page.cc#n615

where width / height is read from PDF file. Some validation of the values is done in Page::loadThumb(), but it is not sufficient to prevent the overflow:

if (width > INTMAX / 3 / height)

http://cgit.freedesktop.org/poppler/poppler/tree/poppler/Page.cc#n547

This code does not exist in poppler as shipped in EL5, nor it is part of xpdf.

oCERT reported an integer overflow flaw during the C++ object allocation leading to a heap overflow discovered by Chris Rohlf, affecting xpdf's / poppler's ObjectStream::ObjectStream (XRef.cc).

objs = new Object[nObjects];

As new[] as implemented in gcc / libstdc++ does not perform integer overflow check [1], sufficiently large nObjects value (read from the input PDF file) can cause integer overflow / wrap when multiplied by sizeof(Object) resulting in insufficient memory allocation.

Affected code was introduced in Xpdf 3.00, packages including / based on this version are affected by this flaw. In Red Hat Enterprise Linux, that means: - xpdf - el4 - gpdf - el4 - poppler - el5 - kdegraphics - el4, el5 - cups - el5 - tetex - el5

Patch attempting to address this was previously added to poppler, but it incorrectly used sizeof(int) instead of sizeof(Object) [2] and hence was insufficient.

[1] http://gcc.gnu.org/bugzilla/showbug.cgi?id=19351 [2] http://cgit.freedesktop.org/poppler/poppler/commit/?id=c36d8afc http://cgit.freedesktop.org/poppler/poppler/commit/?id=f41fa9ee

Acknowledgements:

Red Hat would like to thank Chris Rohlf for reporting this issue.

An array indexing error was found in the way xpdf / poppler parsed Type1 fonts embedded in PDF documents. In FoFiType1::parse(), text representation of the numeric code value was converted to integer value using atoi(). This value was checked to ensure it's less than 256, but there was no check to ensure it's not negative (string passed to atoi() was checked to only contain characters '0'-'9' before the call though). On platforms, where atoi() could return negative result when parsing large positive values (exceeding INTMAX), this could could lead to write out of array bounds due to use of negative index.

poppler upstream commit: http://cgit.freedesktop.org/poppler/poppler/commit/?id=39d140bfc0b8239bdd96d6a55842034ae5c05473

Reference: http://secunia.com/advisories/41596/

PDFunite 0.41.0 contains a buffer overflow vulnerability that allows local attackers to crash the application by processing malformed PDF files during merge operations. Attackers can trigger a segmentation fault in the XRef::getEntry function within libpoppler by providing a specially crafted PDF file to the pdfunite utility.

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.

An invalid free() flaw was found in xpdf's JBIG2 decoder. If a malicious PDF file could free() attacker controlled data, it may be possible to execute arbitrary code 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 "input validation flaws" in the JBIG2 decoder in Xpdf 3.02pl2 and earlier, CUPS 1.3.9 and earlier, Poppler before 0.10.6, and other products allow remote attackers to execute arbitrary code via a crafted PDF file.

An array indexing error was found in the way xpdf / poppler parsed Type1 fonts embedded in PDF documents. In FoFiType1::parse(), text representation of the numeric code value was converted to integer value using atoi(). This value was checked to ensure it's less than 256, but there was no check to ensure it's not negative (string passed to atoi() was checked to only contain characters '0'-'9' before the call though). On platforms, where atoi() could return negative result when parsing large positive values (exceeding INTMAX), this could could lead to write out of array bounds due to use of negative index.

poppler upstream commit: http://cgit.freedesktop.org/poppler/poppler/commit/?id=39d140bfc0b8239bdd96d6a55842034ae5c05473

Reference: http://secunia.com/advisories/41596/

Buffer overflow in the ABWOutputDev::endWord function in poppler/ABWOutputDev.cc in Poppler (aka libpoppler) 0.10.6, 0.12.0, and possibly other versions, as used by the Abiword pdftoabw utility, allows user-assisted remote attackers to cause a denial of service and possibly execute arbitrary code via a crafted PDF file.

Multiple integer overflows in Poppler 0.10.5 and earlier allow remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code via a crafted PDF file, related to (1) glib/poppler-page.cc; (2) ArthurOutputDev.cc, (3) CairoOutputDev.cc, (4) GfxState.cc, (5) JBIG2Stream.cc, (6) PSOutputDev.cc, and (7) SplashOutputDev.cc in poppler/; and (8) SplashBitmap.cc, (9) Splash.cc, and (10) SplashFTFont.cc in splash/. NOTE: this may overlap CVE-2009-0791.

The CairoFont::create function in CairoFontEngine.cc in Poppler, possibly before 0.8.0, as used in Xpdf, Evince, ePDFview, KWord, and other applications, does not properly handle embedded fonts in PDF files, which allows remote attackers to execute arbitrary code via a crafted font object, related to dereferencing a function pointer associated with the type of this font object.

A use-after-free (write) vulnerability has been detected in Poppler within the StructTreeRoot class. The issue arises from the use of raw pointers to elements of a std::vector, which can lead to dangling pointers when the vector is resized.

Poppler is a PDF rendering library. Versions prior to 25.06.0 use std::atomicint for reference counting. Because std::atomicint is only 32 bits, it is possible to overflow the reference count and trigger a use-after-free. Version 25.06.0 patches the issue.

A floating-point exception in the PSStack::roll function of Poppler before 25.04.0 can cause an application to crash when handling malformed inputs associated with INTMIN.

Xpdf, as used in products such as gpdf, kpdf, pdftohtml, poppler, teTeX, CUPS, libextractor, and others, allows attackers to cause a denial of service (crash) via a crafted FlateDecode stream that triggers a null dereference.

The CCITTFaxStream::CCITTFaxStream function in Stream.cc for xpdf, gpdf, kpdf, pdftohtml, poppler, teTeX, CUPS, libextractor, and others allows attackers to corrupt the heap via negative or large integers in a CCITTFaxDecode stream, which lead to integer overflows and integer underflows.

An integer overflow was found in poppler's SplashBitmap::SplashBitmap method. A malicious PDF file could cause poppler to execute with permissions of the user calling the library.

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.