width/length dimensions read from bmp headers are not necessarily
valid. For instance they may have been maliciously set to very large
values with the intention to cause DoS (large memory allocation, stack
overflow). In these cases we want to detect the invalid size as early
as possible.
This commit introduces a counter which verifies that the number of
written bytes corresponds to the advertized width/length.
Fixes#1059 (CVE-2018-6616).
Tile components in a JP2 image might have null data pointer by defining a
zero component size (for example using large horizontal or vertical
sampling periods). This null data pointer leads to null image component
data pointer, causing crash when dereferenced without != null check in
imagetopnm.
Add != null check.
This commit addresses #1152 (CVE-2018-18088).
* Fix some potential overflow issues
Put sizeof to the beginning of the multiplication to enforce that
size_t instead of smaller integer types is used for the calculation.
This fixes warnings from LGTM:
Multiplication result may overflow 'unsigned int'
before it is converted to 'unsigned long'.
It also allows removing some type casts.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
* Fix code indentation
Signed-off-by: Stefan Weil <sw@weilnetz.de>
This uses snprintf() with correct buffer length instead of sprintf(), which
prevents a buffer overflow when providing a long output prefix. Furthermore
the program exits with an error when the provided output prefix is too long.
Fixes#1088.
In the case where a BMP file declares compression 3 (BI_BITFIELDS)
with header size <= 56, all bitmask values keep their initialization
value 0. This may lead to various undefined behavior later e.g. when
doing 1 << (l_comp->prec - 1).
This issue does not affect files with bit count 16 because of a check
added in 16240e2 which sets default values to the color masks if they
are all 0.
This commit adds similar checks for the 32 bit case.
Also, if a BMP file declares compression 3 with header size >= 56 and
intentional 0 bitmasks, the same issue will be triggered in both the
16 and 32 bit count case.
This commit adds checks to bmp_read_info_header() rejecting BMP files
with "intentional" 0 bitmasks. These checks might be removed in the
future when proper handling of zero bitmasks will be available in
openjpeg2.
fixes#1057 (CVE-2018-5785)
This adds the appropriate variables to the invocation of fprintf(). They were
specified in the format string, but were missing in the actual call. This
fixes#1074 and #1075.
Coverity report:
CID 179466 (#1 of 1): Resource leak (RESOURCE_LEAK)
93. leaked_storage: Variable name going out of scope leaks the storage it points to.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
This adds a opj_set_decoded_components(opj_codec_t *p_codec,
OPJ_UINT32 numcomps, const OPJ_UINT32* comps_indices) function,
and equivalent "opj_decompress -c compno[,compno]*" option.
When specified, neither the MCT transform nor JP2 channel transformations
will be applied.
Tests added for various combinations of whole image vs tiled-based decoding,
full or reduced resolution, use of decode area or not.
* Better document usage of opj_set_decode_area(), ie expecting coordinates
in full resolution/reference grid even if requesting at a lower resolution
factor
* Make sure that image->comps[].factor is set by opj_set_decode_area() and
opj_decode() from the value specified in opj_set_decoded_resolution_factor()
* opj_decompress: add 2 environmenet variables to test alternate ways of
using the API, namely USE_OPJ_SET_DECODED_RESOLUTION_FACTOR=YES to use
opj_set_decoded_resolution_factor() instead of parameters.cp_reduce, and
SKIP_OPJ_SET_DECODE_AREA=YES to not call opj_set_decode_area() if -d is
not specified.
Even Rouault
Hugo Lefeuvre
Even Rouault
Young Xiao
Stefan Weil
Nikola Forró
Karol Babioch
szukw000
Karol Babioch
Andrew Murray
Gregory Fiumara
Antonin Descampe