| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When searching for markers in a stream buffer, we were "seeking" to the point
in the buffer, and casting to either a byte, ushort or a uint to make the
value comparison. But we cannot do that on SPARC because of the strict
alignment on that hardware.
So, we have to "unpack" the individual bytes from the stream to do the value
comparison.
Note: there are slightly confusing comments in the code that mention being
"on a 16 bit boundary" and "on a 32 bit boundary" - that's referring to the
offset into the buffer, *not* the actual memory address alignment.
Found in testing on Solaris/SPARC
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The MMR decoder pre-buffers up to 32 bits of encoded input data in a word
buffer before they are consumed by the MMR decoder. Once bits are consumed, the
pre-buffer will be filled up with more input data. When filling up the buffer
the decoder would previously stay clear of reading data belonging to succeeding
segments, but still indicated that it consumed those bytes it never read. Once
finished the MMR decoder lied to the caller by propagating the incorrect number
of consumed bytes. The caller subtracted the consumed number of bytes from the
size and end up in underflow causing the next MMR decoding to first read input
data at the wrong location, later ending up attempting to read outside the MMR
encoded input buffer.
Now, the MMR decoder keeps track of how many bits it has consumed and
accurately rounds this number up to a whole number of bytes to the caller.
Fixes OSS-fuzz issue 17855.
Thanks to OSS-fuzz for reporting.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
According to the JBIG2 specification segments numbers are 32 bit unsigned
integer. Previously any segment numbers larger than INT32_MAX would be passed
as negative numbers.
Some parts of the decoder do not yet know, or do not have access to the
currently decoded segment number, and this needs to be specially indicated.
Therefore jbig2dec appropriates the unlikely segment number 0xffffffff to
indicate an unknown segment number.
This is a change of the public API.
|
| |
|
|
|
| |
Also move UINT32_MAX/INT32_MAX to internal header so they are defined
(the same) in every jbig2 source code file.
|
| |
|
|
|
|
|
|
|
|
| |
Previous code could overflow if w >= 2^32 - 32, breaking behaviour of 'if'
statements and causing incorrect behaviour (including assert failures).
The fix is due to sebras - change expressions such as (x + 32 > w) to (w - x <
32) to avoid overflow for very large w. (We know at all times that x <= w.)
Thanks for OSS-Fuzz for reporting.
|
| |
|
|
|
|
|
| |
This was a hotspot after optimsation of jbig2_compose_image.
Rather than step through each bit in turn, we now look 8, 16 and 32-bit at a
time.
|
| | |
|
| |
|
|
| |
Previously these were fatal errors, now warn and continue.
|
| |
|
|
| |
Previously this unnecessarily happened multiple times.
|
| |
|
|
|
| |
A few lines of code prior if a0 is set before the scanline it is
reset to index 0, so no need to recheck for this condition.
|
| | |
|
| |
|
|
|
| |
Previously these errors led to spurious negative values for runlengths,
which were treated as if these were legal even though they are not.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
According to the T.6 specification the pixel references, e.g. a0,
may point to any of the pixels (indices 0 through N-1) on a
scanline, one pixel to the left of a scanline (index MINUS1) or
one pixel beyond the scanline (index N). These indicies are all
positive (despite its name MINUS1 is defined to UINT32_MAX).
This commit changes the index type from signed to unsigned to
reflect this. Moreover, when looking for changing elements,
make sure to limit the returned index to N.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Chapter 6.2.6 in the JBIG2 specification states that MMR-encoded
data _may_ skip the EOFB code when the data length is known in
advance. If the data length is _not_ known in advance EOFB is
required. Since an encoder may choose to use or skip EOFB when
the data length is known, decoders must always be prepared to
handle EOFB regardless of whether the data length is known or
unknown.
After encountering EOFB jbig2dec now stops consuming MMR-coded
data regardless of whether the data lenght is known in advance
or not. The remainder of the decoded image region is filled with
white.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the file Bug688080.pdf in bug 693798 e.g. has an object 668
containing a JBIG2 bitstream containing an MMR-coded region where the
width of the region is 32 pixels. At one point while decoding this
image, a0 is in the middle of the line and because of the decoded black
and white runs both a1 and a2 end up at the pixel just beyond the end
of the line. At this point jbig2dec would access the byte supposedly
containing this pixel beyond the end of the line, but that is not
allowed. Because this byte was written back unchanged no real harm was
done, but the access was still being performed, triggering software
like valgrind/ASAN that detects buffer overflows.
This commit also reverts the incorrect fix for bug 693798
introduced in commit 46d6b40803cb7a68ceb06b2f71db8cf3f384c2ee
where the allocated image buffer was simply extended by one byte,
thereby accommodating the illegal access.
|
| |
|
|
|
| |
Because jbig2_error(ctx, JBIG2_SEVERITY_WARNING, ...) now returns -1,
it can be immediately returned or assigned as a return code.
|
| | |
|
| |
|
|
|
| |
Accept some whitespace changes as done by the commands
from commit d3d767d9b91ae7d82c261fbdfd735f3042161032.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some functions detected errors but would not return these
to the caller. These functions may now indicate errors:
jbig2_arith_decode(), jbig2_image_resize()
Errors detected by following functions were not always
handled, but they are now handled properly:
jbig2_arith_decode(), jbig2_arith_iaid_decode()
jbig2_arith_int_ctx_new(), jbig2_build_huffman_table()
jbig2_complete_page(), jbig2_image_compose()
jbig2_decode_refinement_region(), jbig2_ctx_new()
jbig2_image_resize(), jbig2_image_write_pbm()
jbig2_image_write_pbm_file(), jbig2_image_write_png()
jbig2_image_write_png_file(), jbig2_metadata_add()
jbig2_page_add_result(), jbig2_renew()
jbig2_strndup()
Some functions detected errors but did not fail early enough:
jbig2_decode_pattern_dict(), jbig2_decode_halftone_region()
jbig2_decode_mmr_line() detected errors but did not produce
suitable error messages. This has been rectified.
Finally, if a subfunction indicates an error by returning an
error code, the calling function will report a warning and
return, indicating failure.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Also update copyright dates.
Remove gs_cmdl.ps as we no longer use it, and remove its entry from
psfiles.htm.
Remove xfonts.htm as this feature (xfont support) is long, long gone.
|
| | |
|
| |
|
|
|
| |
Also rename "new" to "new_dict", because "new" is a bad
variable name.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
First a pass through gnu indent:
indent \
-bad -nbap -nsob -br -ce -cli0 \
-npcs -ncs -i4 -di0 -psl -lp -lps -nut -l160 \
*.c *.h
Followed by astyle to patch over some of the indentation bugs in gnu indent:
astyle --style=kr -H -U -k3 *.c *.h
|
|
|
Squashed into one commit (see branch for details of the evolution of the
branch).
This brings gpcl6 and gxps into the Ghostscript build system, and a shared
set of graphics library object files for all the interpreters.
Also, brings the same configuration options to the pcl and xps products as we
have for Ghostscript.
|
