AI_ONLY_REPORT
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 `surface_width * repeatX` or `surface_height * repeatY` to overflow a 32-bit signed `int`.
3. Trigger the Splash rendering path, for example:
`pdftoppm -f 1 -singlefile poc_tiling_overflow.pdf output-prefix`
4. Observe AddressSanitizer reporting a heap out-of-bounds write in `tilingBitmapSrc` during `drawImage` processing.


Vulnerability Details






`result_width` and `result_height` are computed using unchecked signed multiplication and then passed to `drawImage()`:
```cpp
result_width = surface_width * repeatX;
result_height = surface_height * repeatY;
...
retValue = splash->drawImage(&tilingBitmapSrc, nullptr, &imgData, colorMode, true,
result_width, result_height, matc, false, true) == splashOk;
```
However, the source callback still writes based on `repeatX` and the tile width rather than the possibly overflowed `result_width`:
```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 *)gmallocn_checkoverflow(srcWidth, nComps);
```
If `surface_width * 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 (surface_width == 0 || surface_height == 0 || repeatX * repeatY <= 4) {
+ int repeatArea = 0;
+ if (surface_width == 0 || surface_height == 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(...)

result_width = surface_width * repeatX;

result_height = surface_height * repeatY;
+ if (checkedMultiply(surface_width, repeatX, &result_width) ||
+ checkedMultiply(surface_height, repeatY, &result_height) ||
+ result_width <= 0 || result_height <= 0) {
+ state->setCTM(savedCTM[0], savedCTM[1], savedCTM[2], savedCTM[3], savedCTM[4], savedCTM[5]);
+ return false;
+ }
+
 kx = result_width / (fabs(kx) + 1);
 ky = result_height / (fabs(ky) + 1);
```


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