An integer overflow in opj_pi_create_decode of pi.c was found that leads to out-of-bounds read and write in opj_pi_next_cprl of pi.c. Upstream fix: https://github.com/uclouvain/openjpeg/commit/c16bc057ba3f125051c9966cf1f5b68a05681de4 https://github.com/uclouvain/openjpeg/commit/ef01f18dfc6780b776d0674ed3e7415c6ef54d24 CVE assignment: http://seclists.org/oss-sec/2016/q3/442
Created openjpeg tracking bugs for this issue: Affects: fedora-all [bug 1374339]
Created mingw-openjpeg tracking bugs for this issue: Affects: fedora-all [bug 1374341]
Created openjpeg2 tracking bugs for this issue: Affects: fedora-all [bug 1374340] Affects: epel-all [bug 1374343]
Created mingw-openjpeg2 tracking bugs for this issue: Affects: fedora-all [bug 1374342]
Test case is now included in the openjpeg-data repo: https://github.com/uclouvain/openjpeg-data/blob/master/input/nonregression/issue826.jp2
Upstream ticket (CVE assignment): https://github.com/uclouvain/openjpeg/issues/826 More detail: https://github.com/uclouvain/openjpeg/issues/825
openjpeg2-2.1.1-3.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
openjpeg2-2.1.1-3.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
mingw-openjpeg2-2.1.1-3.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
mingw-openjpeg2-2.1.1-3.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
openjpeg2-2.1.1-3.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
mingw-openjpeg2-2.1.1-3.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
Openjpeg-1 is tickled by the same reproducer, but the crash is in a completely different place. I think it may require a distinct patch. The ASAN warning is the same with upstream 1.5.1, 1.5.2 and RHEL patched versions: ==13320==WARNING: AddressSanitizer failed to allocate 0xfffffff400000300 bytes ==13320==AddressSanitizer's allocator is terminating the process instead of returning 0 ==13320==If you don't like this behavior set allocator_may_return_null=1 ==13320==AddressSanitizer CHECK failed: /builddir/build/BUILD/llvm-3.4.2.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_allocator.cc:149 "((0)) != (0)" (0x0, 0x0) #0 0x46d29f in __asan::AsanCheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) (/home/dmoppert/repros/openjpeg/git-openjpeg/build-1.5.2/bin/j2k_to_image+0x46d29f) #1 0x472b01 in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) (/home/dmoppert/repros/openjpeg/git-openjpeg/build-1.5.2/bin/j2k_to_image+0x472b01) #2 0x471840 in __sanitizer::AllocatorReturnNull() (/home/dmoppert/repros/openjpeg/git-openjpeg/build-1.5.2/bin/j2k_to_image+0x471840) #3 0x467336 in malloc (/home/dmoppert/repros/openjpeg/git-openjpeg/build-1.5.2/bin/j2k_to_image+0x467336) #4 0x7fc7f1b8a995 in tcd_malloc_decode_tile /home/dmoppert/repros/openjpeg/git-openjpeg/libopenjpeg/tcd.c:804 #5 0x7fc7f1a615cf in j2k_read_eoc /home/dmoppert/repros/openjpeg/git-openjpeg/libopenjpeg/j2k.c:1691 #6 0x7fc7f1a775d8 in j2k_decode /home/dmoppert/repros/openjpeg/git-openjpeg/libopenjpeg/j2k.c:2027 #7 0x7fc7f1aa856e in opj_jp2_decode /home/dmoppert/repros/openjpeg/git-openjpeg/libopenjpeg/jp2.c:841 #8 0x7fc7f1ad6379 in opj_decode_with_info /home/dmoppert/repros/openjpeg/git-openjpeg/libopenjpeg/openjpeg.c:168 #9 0x7fc7f1ad5c9b in opj_decode /home/dmoppert/repros/openjpeg/git-openjpeg/libopenjpeg/openjpeg.c:157 #10 0x47fca2 in main /home/dmoppert/repros/openjpeg/git-openjpeg/applications/codec/j2k_to_image.c:681 #11 0x7fc7f0221b14 in __libc_start_main (/lib64/libc.so.6+0x21b14) #12 0x47d3dc in _start (/home/dmoppert/repros/openjpeg/git-openjpeg/build-1.5.2/bin/j2k_to_image+0x47d3dc) Overflow is coming from the multiplication in tcd_malloc_decode_tile(): band->precincts = (opj_tcd_precinct_t *) opj_malloc(res->pw * res->ph * sizeof(opj_tcd_precinct_t)); Putting some printf()s before this shows res->pw, res->ph taking on a lot of negative values. It looks like opj_int_ceildivpow2() is going wrong earlier; a patch along the lines of below is probably needed: https://github.com/uclouvain/openjpeg/commit/38770403d From a ticket referenced in that commit <https://github.com/uclouvain/openjpeg/issues/388>: > seems the segfault came from a bug in a math function implementation (int_ceildivpow2). > It had already been fixed in trunk but not yet backported in 1.5.
> openjpeg-1.x is not affected by this flaw. This report led to the discovery of CVE-2016-9675. This observation was incorrect - Nikola Forró has provided a patch for this flaw on bug 1382202.
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Via RHSA-2017:0559 https://rhn.redhat.com/errata/RHSA-2017-0559.html
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2017:0838 https://rhn.redhat.com/errata/RHSA-2017-0838.html