An integer overflow vulnerability was found in jasper in jas_image.c triggered by parsing of a maliciously crafted file. Upstream patch: https://github.com/mdadams/jasper/commit/d42b2388f7f8e0332c846675133acea151fc557a References: http://seclists.org/oss-sec/2016/q4/470
Created mingw-jasper tracking bugs for this issue: Affects: fedora-all [bug 1396987]
Created jasper tracking bugs for this issue: Affects: fedora-all [bug 1396986]
Upstream bug report: https://github.com/mdadams/jasper/issues/67 Original reporter's advisory: https://blogs.gentoo.org/ago/2016/11/19/jasper-signed-integer-overflow-in-jas_image-c/ Relevant information from the advisory: The undefined behavior sanitizer shows a signed integer overflow in jas_image.c As you can see, the commit which fixes the issue is not a fix itself for the signed integer overflow, but changed a bit how, in jasper, the things work. The complete UBSan output: # imginfo -f $FILE /tmp/portage/media-libs/jasper-1.900.17/work/jasper-1.900.17/src/libjasper/base/jas_image.c:162:49: runtime error: signed integer overflow: 8543608947741818625 * 15 cannot be represented in type 'long' Affected version: 1.900.17 Fixed version: 1.900.25 Commit fix: https://github.com/mdadams/jasper/commit/d42b2388f7f8e0332c846675133acea151fc557a
There is crash/abort when jasper is compiles with undefined behaviour sanitizer (ubsan) enabled. That is a development tool aimed to identify possible code bugs related to undefined behaviour. There is no crash for builds not using ubsan (as is the case for jasper packages in Red Hat Enterprise Linux and Fedora). The integer overflow is in the code that computes an approximate memory requirement for the image to decide if date should be stored in memory on in a temporary file. This bug could cause jasper to use memory storage when use of temporary file was intended. The actual memory allocations are protected against integer overflows because of CVE-2015-5203 (bug 1254242) / CVE-2016-9262 (bug 1393882). Upstream commit d42b238 changed the code to do the memory requirement estimate separately for each component, rather than as summary for all components. Therefore, to trigger large memory use, the image needs to contain many components with size close to the threshold. Not considering this security issue for non-ubsan builds.