| Age | Commit message (Collapse) | Author |
|---|
|
When running a softmask, we remove the softmask from the gstate,
then run the group contents, then put the softmask back.
If the gstate stack is moved in the meantime (due to it being
realloced for extension), we can end up with it being moved.
We therefore must recalculate gstate before writing again.
Problem found in a test file, pdf_001/2599.pdf.asan.58.1778 supplied
by Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google
Security Team using Address Sanitizer. Many thanks!
|
|
While investigating samples_mupdf_001/2599.pdf.asan.58.1778, a leak
showed up while cleaning the file, due to not dropping an object in
an error case.
mutool clean -dif samples_mupdf_001/2599.pdf.asan.58.1778 leak.pdf
Simple Fix. Also extend PDF writing so that it can cope with skipping
errors so we at least get something out at the end.
Problem found in a test file supplied by Mateusz "j00ru" Jurczyk and
Gynvael Coldwind of the Google Security Team using Address Sanitizer.
Many thanks!
|
|
If an OCG refers to itself, we end up recursing forever and
eventually stack overflow. Fix with the pdf_dict_mark stuff.
Problem found in 1551.pdf.SIGSEGV.7fd.615, a test file supplied by
Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google Security
Team using Address Sanitizer. Many thanks!
|
|
With added comment to explain the funky boolean logic.
|
|
The pdf function code only expects a maximum of FZ_MAX_COLORS
component functions in a sampling function; more functions than
this causes a buffer overflow. Add some checks to avoid this.
Problem found in 1219.pdf.SIGSEGV.fc0.246, a test file supplied by
Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google Security
Team using Address Sanitizer. Many thanks!
|
|
Two problems with tiling are fixed here.
Firstly, if the tiling bounds are huge, the 'patch' region (the region
we are writing into), can overflow, causing a SEGV due to the paint code
being very confused by pixmaps that go from just under INT_MAX to just
over INT_MIN. Fix this by checking explicitly for overflow in these
bounds.
If the tiles are stupidly huge, but the scissor is small, we can end up
looping many more times than we need to. We fix mapping the scissor
region back through the inverse transform, and intersecting this
with the pattern area.
Problem found in 4201.pdf.SIGSEGV.622.3560, a test file supplied by
Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google Security
Team using Address Sanitizer. Many thanks!
|
|
If the key length is specified too long (0x120 for example), we can
overrun the key buffer (32 bytes). Fix this with some explicit
checks.
Problem found in 2513.pdf.asan.73.1684, a test file supplied by
Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google Security
Team using Address Sanitizer. Many thanks!
|
|
|
|
When calculating the bbox for draw_glyph, if the x and y origins of
the glyph are extreme (too large to fit in an int), we get overflows
of the bbox; empty bboxes are transformed to large ones.
The fix is to introduce an fz_translate_bbox function that checks for
such things.
Also, we update various bbox/rect functions to check for empty bboxes
before they check for infinite ones (as a bbox of x0=0 x1=0 y0=0 y1=-1
will be detected both as infinite and empty).
Problem found in 2485.pdf.SIGSEGV.2a.1652, a test file supplied by
Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google Security
Team using Address Sanitizer. Many thanks!
|
|
This makes searching for things much easier.
|
|
Also removed the split between onCreate and onResume. No idea why I
introduced that in the first place.
|
|
It is perfectly allowable to have type3 glyphs that refer to
other type3 glyphs in the same font (and in theory it's probably
even possible to have type3 glyphs that refer back and forth
between 2 or more type3 fonts).
The old code used to cope with this just fine, but with the change
to 'early loading' of the glyphs to display lists at interpret time
a problem has crept in. When we load the type 3 font, we load
each glyph in turn. If glyph 1 tries to use glyph 2, then we look
up the font, only to find that that the font has not been installed
yet, so we reload the entire font. This gets us into an infinite
loop.
As a fix for this, we split the loading of the type3 font into 2; we
load the font as normal, then allow the font to be inserted into
the list of current fonts. Then we run through the glyphs in the
font 'preparing' them (turning them into display lists).
This solves the infinite loop issue, but causes another problem;
recursive references (such as a font holding a display list that
contains a text node that contains a reference to the original font)
result in us never being able to free the structures.
To avoid this, we insist on never allowing type3 glyphs to be referenced
within a type3 display list. The display lists for all type3 glyphs
are therefore 'flat'. We achieve this by adding a 'nested' flag to
the pdf command stream interpreter structure, and setting this in the
case where we are running a glyph stream. We check for that flag in the
type3 glyph render function, and if present, we force the 'render_direct'
path to be used.
Finally, we ensure that fz_text groups are not needlessly created with
no contents.
Problem found in 2923.pdf.asan.22.2139, a test file supplied by
Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google Security
Team using Address Sanitizer. Many thanks!
|
|
With a small dst_w (e.g. 1e-23) the floating point maths governing
scales can go wrong in the weight calculations. MSVC in particular
seems to return 1<<31 for the result of the max_len calculation.
It makes no real sense to scale bitmaps to < 1 pixel, so simply clamp
width and height as required.
Problem found in 2923.pdf.asan.22.2139, a test file supplied by
Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google Security
Team using Address Sanitizer. Many thanks!
|
|
Leaking long linked lists leads to stack overflows during the
Memento debug output. Avoid this by iterating rather than recursing
where possible.
Also, for sanities sake, where we intent more than 40 spaces, use a
single '*' instead. This keeps logfiles sane.
|
|
When extreme ranges (+/- MAX_INT) are passed into the scaler
signed wrap around gives us problems when calculating the patch.
Simply ignore such cases.
Problem found in 1792.pdf.SIGSEGV.387.883, a test file supplied by
Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google Security
Team using Address Sanitizer. Many thanks!
|
|
Whenever we have an error while pushing a gstate, we run the risk of
getting confused over how many pops we need etc.
With this commit we introduce some checking at the dev_null level that
attempts to make this behaviour consistent.
Any caller may now assume that calling an operation that pushes a clip
will always succeed. This means the only error cleanup they need to
do is to ensure that if they have pushed a clip (or begun a group, or
a mask etc) is to pop it too.
Any callee may now assume that if it throws an error during the call
to a device entrypoint that would create a group/clip/mask then no more
calls will be forthcoming until after the caller has completely finished
with that group.
This is achieved by the dev_null layer (the layer that indirects from
device calls through the device structure to the function pointers)
swallowing errors and regurgitating them later as required. A count is
kept of the number of pushes that have happened since an error
occurred during a push (including that initial one). When this count
reaches zero, the original error is regurgitated. This allows the
caller to keep the cookie correctly updated.
|
|
|
|
|
|
With illegal fax streams we could access beyond the right hand edge
of the allocated line. Fix this by adding some simple checks.
Issue found by Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the
Google Security Team using Address Sanitizer. Many thanks!
|
|
We failed to detect a PDF sample function with a size of 0 as being
illegal. This lead us to continue through the code, and then access
out of bounds.
Issue found by Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the
Google Security Team using Address Sanitizer. Many thanks!
|
|
If an illegal keysize is passed into the AES crypt filter, we
currently exit without setting up the AES context. This causes
us to fail in all manner of ways later on.
We now return failure and callers throw an exception.
This appears to solve all the SEGVs and memory exceptions found in
crypt_aes by Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the
Google Security Team using Address Sanitizer. Many thanks!
|
|
Another patch from zeniko; if we read an unknown cmd while parsing
a path string, ensure that we skip over any subsequent numbers to
avoid going into an infinite loop.
|
|
A user (stu-mupdf) points out that if winopen fails, we throw
an error, which crashes due to the exception stack not having
been set up yet. The solution is simply to move pdfapp_init a
little earlier.
|
|
A user (av1474) points out that pthread error codes are non zero,
not negative; hence fix the example code to test for these
correctly.
|
|
Move the TR2 handling code. Thanks to zeniko for this.
|
|
Another fix from zeniko. Thanks again.
|
|
The issues fixed here were found by zeniko - many thanks.
The patch here is our own work - larger change, avoiding casts
for a (hopefully) neater result.
|
|
Thanks to zeniko for pointing this out. If we encounter a new definition
for a given object (presumably due to a repair operation), we used to
throw the old one away, and keep the new one. This could cause any
current holders of the object to be left with a stale pointer.
Now we throw the new one away and keep the old one - with a warning
if they are different.
|
|
Thanks to zeniko for these.
|
|
|
|
The way the forms to be reset is specified is used also in form
submission. This commit pulls out that selection method as a
separate function that returns the set of affected forms as a
pdf array object.
|
|
Following on from the blend.ai.pdf disapparing text fix that went in
the other day, zeniko has pointed out that we should be using the
device space on entry to pdf_show_pattern too. Fixed here.
Many thanks.
|
|
Thanks to zeniko for pointing out that the recent changes to
the fz_try/fz_catch macros to allow for throws in the fz_always
block had broken the exception stack overflow case.
Thanks also for the example file (nesting stack overflow.pdf),
which has now been added to the regression suite.
|
|
Thanks to zeniko for the heads up.
|
|
Add a mechanism for getting a color converter function. Implement
the 'convert a single color' call in terms of that. 'Bulk' users
can then repeatedly call the single function.
|
|
When creating a group around text, the text bbox was being used as the
group bbox without transforming it. This results in missing text in
blends.
Various text sections are now appearing in some test files too.
|
|
A NULL pointer dereference could be caused in error cases due
to me failing to apply zenikos patch correctly.
|
|
In doing this work, it strikes me that there is an unoptimised case
left in the aa scan conversion; when we are plotting whole scanlines
with gel->alen = 0, we can skip the entire blit. This happens
relatively rarely so the extra cost of the test may be more than
is worthwhile.
|
|
|
|
|
|
Fixes warning at launch and autorotation not working on iOS 6.
|
|
Sort the file list rather than the list adapter, so that
the onclick position can validly be used to index the file list
|
|
Remove unnecessary hitPageLink method from MuPDFCore and extend the
handling of external links to the java classes
|
|
|
|
Throwing from within the always block is bad practice, but attempt
to cope with it gracefully.
|
|
Turns out that jpeg_finish_decompress can throw errors, hence
can cause an infinite loop. This is fixed here by changing the
jpeg error code to be fz_throw based.
Thanks to zeniko for this patch.
This highlights something that I hadn't fully appreciated before;
anything that throws in a fz_always region will reenter that region.
I think I have a way to fix this so that any throws in the
fz_always region go immediately to the fz_catch.
|
|
We now have a libmupdf that has all the usual files in, plus a
libmupdf-v8 and a libmupdf-nov8 with/without javascript
respectively. libmupdf-v8 and libmupdf-nov8 both depend on libmupdf,
and the apps depend on libmupdf-{no,}v8 as appropriate.
This means every file is listed (and compiled) strictly once, and
better matches the style of the unix builds. It also prevents VS
getting confused and listing files twice in search results.
Also, we strip out the unnecessary repeated calls to generate.bat,
which result in occasional spurious build failures.
|
|
Various changes from zeniko to make the pdf interpreter cope better
with malformed files.
When running subobjects, catch the thrown errors to avoid upsetting
the clip stack.
When running a content stream, ensure that we don't underflow the
graphics states (in case of mismatched q/Q's). Here our patch
differs slightly from zeniko's original, as we pop any extra
ones off before returning.
|
|
Fix an issue spotted by zeniko. The patch is slightly modified
from his supplied one to avoid problems with repeated freeing
of the buffer, and to avoid abusing fz_buffer, but is largely
based on his work.
Many thanks.
|
|
Thanks to zeniko for finding various problems and submitting a
patch that fixes them. This commit covers the simpler issues from
his patch; other commits will follow shortly.
* Out of range LZW codes.
* Buffer overflows and error handling in image_jpeg.c
* Buffer overflows in tiff handling
* buffer overflows in cmap parsing.
* Potential double free in font handling.
* Buffer overflow in pdf_form.c
* use of uninitialised value in error case in pdf_image.c
* NULL pointer dereference in xps_outline.c
|
