Bugzilla – Bug 979911
VUL-0: CVE-2016-4797: openjpeg2: Division-by-zero in function opj_tcd_init_tile in tcd.c
Last modified: 2017-09-07 06:36:08 UTC
rh#1335483 Divide by zero vulnerability was found in function opj_tcd_init_tile in tcd.c Upstream patch: https://github.com/uclouvain/openjpeg/commit/8f9cc62b3f9a1da9712329ddcedb9750d585505c CVE request: http://seclists.org/oss-sec/2016/q2/327 CVE assignment: http://seclists.org/oss-sec/2016/q2/342 Note that the problematic "(OPJ_UINT32)-1) / l_data_size" was apparently introduced in a patch addressing out-of-bounds read (or heap-based buffer over-read) vulnerabilities. See the pdfium.googlesource.com reference in CVE-2014-7947. In other words, CVE-2016-4797 exists because of an incorrect fix for CVE-2014-7947. References: https://bugzilla.redhat.com/show_bug.cgi?id=1335483 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-4797 http://seclists.org/oss-sec/2016/q2/342 http://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-4797.html
bugbot adjusting priority
This still affects openSUSE Leap 42.1, 42.2. Please submit maintenance updates. Let us know if you are no longer maintaining.
Sorry for taking so long to reply... This issue does not affect openjpeg but openjpeg2. Function opj_tcd_init_tile does not exist in openjpeg (see also rh#1335483). Reassigning to default since I do not maintain openjpeg2.
We don't have the overflow check at all
As Johannes pointed out, the code in our openjpeg2 looks completely different, and does not use division to compute or check l_data_size. The code we have looks like this: > l_data_size = (OPJ_UINT32)(l_tilec->x1 - l_tilec->x0) > * (OPJ_UINT32)(l_tilec->y1 - l_tilec->y0) * (OPJ_UINT32)sizeof(OPJ_UINT32 ); (sic) l_data_size is then used for the new tile allocation if the size increased. I don't think we need to do anything for this particular CVE. Please let me know if you agree so we can close this or find something else to fix.
Our openjpeg2 code looks the same across Leap 42.2, Leap 42.3, SLE12-SP2+. Thus this is not an issue for us at the moment. Closing this as INVALID.