CVE-2026-10118: Poppler: integer overflow in poppler splashoutputdev::tilingpatternfill leads to heap buffer overflow via unchecked dimension multiplication

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

— Red Hat