A flaw was found in in JasPer 2.0.14. A heap-based buffer over-read in jp2_encode function in jp2/jp2_enc.c file. References: https://github.com/mdadams/jasper/issues/191
Created jasper tracking bugs for this issue: Affects: fedora-all [bug 1664879] Created mingw-jasper tracking bugs for this issue: Affects: epel-7 [bug 1664881] Affects: fedora-all [bug 1664880]
This problem is in the following code in the jp2_encode() function: https://github.com/mdadams/jasper/blob/version-2.0.16/src/libjasper/jp2/jp2_enc.c#L294-L312 There are calls to jas_image_cmpttype() as jas_image_cmpttype(image, 2), where jas_image_cmpttype() is a macro defined as: #define jas_image_cmpttype(image, cmptno) \ ((image)->cmpts_[(cmptno)]->type_) Hence the code attempts to access cmpts_[] array in the image structure as positions 0, 1, and 2. The problem is that the array may not be large enough, it only has size of image->numcmpts_ which may be less than 3 (it is 2 for the reproducer provided in the upstream report). This leads to a short buffer over-read. The value read is used as pointer and dereferenced, leading to invalid (possibly NULL) pointer deference, which is likely to trigger an immediate crash. A possible fix here is to ensure that there are 3 components before performing the relevant checks. I'm not sure if fewer than 3 components should always be handled as error when using RGB or YCBCR color spaces, or if fewer components can be used as long as matching cdef data is also provided. It should be noted that this problem occurs when using the jasper library to convert a specially crafted image into jp2 format. The problem does not affect the most common use case when the library is only used to read images in the JPEG2000 format. The issues remains unfixed in the latest upstream version 2.0.16.
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2018-20570
Upstream commit: https://github.com/jasper-software/jasper/commit/03db7c81f6a8a92d896249bc673877749987fd7a The issue was fixed upstream in jasper 2.0.17.