| Age | Commit message (Collapse) | Author |
|
That could lead to later assertion failures.
Fixes #1231 / CVE-2020-8112
|
|
beyond INT_MAX (fixes #1228)
|
|
pi.c: avoid integer overflow, resulting in later invalid access to memory in opj_t2_decode_packets()
|
|
characters (#1196)
Fixes #1068
|
|
opj_t2_decode_packets(). Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18979
|
|
eal(): proper deal with a number of samples larger than 4 billion (refs #1151)
|
|
Previously the multiple component transformation SGcod(C)
and wavelet transformation SPcod(H)/SPcoc(E) parameter
values were never checked, allowing for out of range values.
The lack of validation allowed the bit stream provided in
issue #1158 through. After this commit an error message
points to the marker segments' parameters as being out of
range.
input/nonregression/edf_c2_20.jp2 contains an SPcod(H) value
of 17, but according to Table A-20 of the specification only
values 0 and 1 are valid. input/nonregression/issue826.jp2
contains a SGcod(B) value of 2, but according to Table A-17
of the specification only values 0 and 1 are valid.
input/nonregression/oss-fuzz2785.jp2 contains a SGcod(B)
value of 32, but it is likewise limited to 0 or 1. These test
cases have been updated to consistently fail to parse the
headers since they contain out of bounds values.
This fixes issue #1210.
|
|
The function is used to read both SPcod and SPcoc, so all
comments should refer to both marker segments' parameter names.
|
|
openjp2/j2k: Report error if all wanted components are not decoded.
|
|
Fix several potential vulnerabilities
|
|
|
|
no POC settings
|
|
|
|
The standard mandates that the layer index always starts at zero for every
progression.
|
|
|
|
|
|
|
|
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.
See commit 8ee335227bbc for details.
Signed-off-by: Young Xiao <YangX92@hotmail.com>
|
|
Fixes #1053 / CVE-2018-5727
Note: I don't consider this issue to be a security vulnerability, in
practice.
At least with gcc or clang compilers on x86_64 which generate the same
assembly code with or without that fix.
|
|
This reverts commit 05be3084460e46282ee63f04c72c451f3271fd28.
This commit doesn't compile due to missing OPJ_UINT64 type
|
|
This reverts commit c277159986c80142180fbe5efb256bbf3bdf3edc.
The commit didn't compile. include_size is not defined in openmj2
|
|
Previously the caller had to check whether each component data had
been decoded. This means duplicating the checking in every user of
openjpeg which is unnecessary. If the caller wantes to decode all
or a set of, or a specific component then openjpeg ought to error
out if it was unable to do so.
Fixes #1158.
|
|
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).
|
|
Fix multiple potential vulnerabilities and bugs
|
|
and fixes unaligned load
Signed-off-by: Young Xiao <YangX92@hotmail.com>
|
|
(CVE-2018-14423
Signed-off-by: Young_X <YangX92@hotmail.com>
|
|
avoid potential int overflow
Signed-off-by: Young_X <YangX92@hotmail.com>
|
|
opj_get_encoding_parameters
Signed-off-by: Young_X <YangX92@hotmail.com>
|
|
Signed-off-by: Young_X <YangX92@hotmail.com>
|
|
Derived from a patch by Thuan Pham
|
|
Signed-off-by: Young_X <YangX92@hotmail.com>
|
|
Signed-off-by: Young_X <YangX92@hotmail.com>
|
|
Signed-off-by: Young_X <YangX92@hotmail.com>
|
|
jp3d/jpwl convert: fix write stack buffer overflow
|
|
When compressing a lot of slices (starting from 44 FullHD slices with 3 8bit components in our experiments) the rate values are high enough to cause an int overflow that leads to negative lengths and wrong results. The cast happens too late.
|
|
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).
|
|
Missing buffer length formatter in fscanf call might lead to write
stack buffer overflow.
fixes #1044 (CVE-2017-17480)
|
|
* 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>
|
|
Signed-off-by: Nikola Forró <nforro@redhat.com>
|
|
|
|
CVE-2018-5785: fix issues with zero bitmasks
|
|
(fixes #1125)
|
|
|
|
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.
|
|
|
|
|
|
Cast on uint ceildiv
|
|
Use local type declaration for POSIX standard type only for MS compiler
|
|
Fix some typos in code comments and documentation
|
|
Changes in pnmtoimage if image data are missing
|