<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
If the big image patches are committed, is it worth adding a command line option to enable or disable big images or to set the max image size so applications that should never see big images don't have to worry about DOS?</div>
<div>
<div id="appendonsend"></div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> poppler <poppler-bounces@lists.freedesktop.org> on behalf of Martin (gzlist) <gzlist@googlemail.com><br>
<b>Sent:</b> Thursday, August 20, 2020 7:43 AM<br>
<b>To:</b> poppler@lists.freedesktop.org <poppler@lists.freedesktop.org><br>
<b>Subject:</b> [poppler] Big image splash support</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="PlainText">I have a patchset to support writing images with more than 2GiB pixel<br>
data using the splash backend, which raises a few questions worth<br>
running past this list.<br>
<br>
Rendering a pdf (using for instance the pdftoppm utility) allocates a<br>
bitmap to draw into and assemble the output. The bitmap dimensions and<br>
coordinates are of type int, and the product is also treated as an<br>
int, both in the gmem allocation, and in drawing logic. On an LP64<br>
system, this means the max image size is under 27500x27500 and quite a<br>
bit less than could fit in memory.<br>
<br>
Large outputs result is this error:<br>
<br>
$ pdftoppm -scale-to 32768 -png ~/sample.ai > /tmp/out.png<br>
Bogus memory allocation size<br>
$ file /tmp/out.png<br>
/tmp/out.png: PNG image data, 1 x 1, 8-bit/color RGB, non-interlaced<br>
<br>
The logged line is from the allocator level check, and after there is<br>
a slightly surprising fallback to 1 pixel square output. From looking<br>
at other [allocator errors] this probably exists so *some* output is<br>
produced for documents with only some bogus content?<br>
<br>
There is an argument that all widths, heights, and coordinates should<br>
be size_t instead of int, but to limit the size and pain of the<br>
change, keeping the current interfaces using int seems reasonable.<br>
<br>
So two distinct changes to make:<br>
* Allocations larger than 2GiB must be allowed<br>
* Buffer offsets must use a type larger than int<br>
Also, optionally:<br>
* Handle failed allocations a little better<br>
<br>
For allocation, what I have currently is (A) change use of int in<br>
gmem.c to long so all allocations can be >2GiB on 64-bit machines.<br>
Alternatively I could (B) find just the uses of the allocator that may<br>
need large areas and make them use a new gmem function.<br>
<br>
Do you prefer (A) or (B) here? Given existing [pdf deflate bombs]<br>
there's probably not much DoS protection provided by the 2GiB limit?<br>
<br>
For the splash code, what I've implemented and propose landing is<br>
casting to size_t on index into a buffer, generally where<br>
multiplication happens. The tradeoff is it's harder to be sure of<br>
correctness - my method of finding where to make changes was a<br>
combination of grep, and gdb with real world inputs.<br>
<br>
Is this acceptable? It's possible this method will introduce memory<br>
safety issues specifically for large output sizes.<br>
<br>
Note the [cairo max size] is explicitly (1<<15)-1 for surface<br>
dimensions, and not addressed by my changes.<br>
<br>
Martin<br>
<br>
<br>
[allocator errors]: Some problems currently blocked at gmalloc level?<br>
<a href="https://gitlab.freedesktop.org/poppler/poppler/-/issues/532">https://gitlab.freedesktop.org/poppler/poppler/-/issues/532</a><br>
<a href="https://gitlab.freedesktop.org/poppler/poppler/-/issues/825">https://gitlab.freedesktop.org/poppler/poppler/-/issues/825</a><br>
<br>
[pdf deflate bombs]: PDF Deflate bombs may cause crashes or resource exhaustion<br>
<a href="https://gitlab.freedesktop.org/poppler/poppler/-/issues/878">https://gitlab.freedesktop.org/poppler/poppler/-/issues/878</a><br>
<br>
[cairo max size]: Limits for the cairo backed<br>
<a href="https://gitlab.freedesktop.org/cairo/cairo/-/blob/1.16/src/cairo-image-surface.c#L59">https://gitlab.freedesktop.org/cairo/cairo/-/blob/1.16/src/cairo-image-surface.c#L59</a><br>
There's been some work in pixman, but it's incomplete?<br>
<a href="https://gitlab.freedesktop.org/pixman/pixman/-/issues/6">https://gitlab.freedesktop.org/pixman/pixman/-/issues/6</a><br>
_______________________________________________<br>
poppler mailing list<br>
poppler@lists.freedesktop.org<br>
<a href="https://lists.freedesktop.org/mailman/listinfo/poppler">https://lists.freedesktop.org/mailman/listinfo/poppler</a><br>
</div>
</span></font></div>
</div>
</body>
</html>