SUSE has issued an advisory on December 27: https://lists.opensuse.org/opensuse-security-announce/2016-12/msg00095.html Mageia 5 is also affected.
Whiteboard: (none) => MGA5TOO
Assigning to maintainer, but CC'ing all packagers collectively, because we haven't heard from the maintainer in a long time. We miss you, fwang, and hope everything's well with you.
CC: (none) => marja11, pkg-bugsAssignee: bugsquad => fundawang
Suggested advisory: ======================== The updated packages fix security vulnerabilities: Floating Point Exception (aka FPE or divide by zero) in opj_pi_next_cprl function in openjp2/pi.c:523 in OpenJPEG 2.1.2. (CVE-2016-9112) There is a NULL pointer dereference in function imagetobmp of convertbmp.c:980 of OpenJPEG 2.1.2. image->comps[0].data is not assigned a value after initialization(NULL). Impact is Denial of Service. (CVE-2016-9113) There is a NULL Pointer Access in function imagetopnm of convert.c:1943(jp2) of OpenJPEG 2.1.2. image->comps[compno].data is not assigned a value after initialization(NULL). Impact is Denial of Service. (CVE-2016-9114) Heap Buffer Over-read in function imagetotga of convert.c(jp2):942 in OpenJPEG 2.1.2. Impact is Denial of Service. Someone must open a crafted j2k file. (CVE-2016-9115) NULL Pointer Access in function imagetopnm of convert.c:2226(jp2) in OpenJPEG 2.1.2. Impact is Denial of Service. Someone must open a crafted j2k file. (CVE-2016-9116) NULL Pointer Access in function imagetopnm of convert.c(jp2):1289 in OpenJPEG 2.1.2. Impact is Denial of Service. Someone must open a crafted j2k file. (CVE-2016-9117) Heap Buffer Overflow (WRITE of size 4) in function pnmtoimage of convert.c:1719 in OpenJPEG 2.1.2. (CVE-2016-9118) References: https://lists.opensuse.org/opensuse-security-announce/2016-12/msg00095.html https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9112 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9113 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9114 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9115 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9116 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9117 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9118 ======================== Updated packages in core/updates_testing: ======================== openjpeg2-2.1.2-1.2.mga5 lib(64)openjp2_7-2.1.2-1.2.mga5 lib(64)openjpeg2-devel-2.1.2-1.2.mga5 from SRPMS: openjpeg2-2.1.2-1.2.mga5.src.rpm
Status: NEW => ASSIGNEDCC: (none) => nicolas.salgueroVersion: Cauldron => 5Assignee: fundawang => qa-bugsWhiteboard: MGA5TOO => (none)
Testing M5_64 There are 3 (2 really) commands to play with: obj_compress Other formats -> jp2 obj_decompress jp2-> other formats [obj_dump Dump a .jp2 .j2k .jpt image to stdout] AFTER the update: lib64openjp2_7-2.1.2-1.2.mga5 openjpeg2-2.1.2-1.2.mga5 Converted sucessfully .bmp .ppm images to j2k/jp2, which displayed OK with ImageMagick. $ opj_compress -i blackbuck.bmp -o blackbuck.j2k [INFO] tile number 1 / 1 [INFO] Generated outfile blackbuck.j2k $ opj_compress -i blackbuck.ppm -o blackbuck.j2k [INFO] tile number 1 / 1 [INFO] Generated outfile blackbuck.j2k .png .tif both FAILED (it does not recognise .tiff). Both source files displayed OK. $ opj_compress -i blackbuck.png -o blackbuck.j2k Unable to load file: got no image $ opj_compress -i blackbuck.tif -o blackbuck.jp2 Unable to load file: got no image The decoding jp2 -> other formats followed the same success (.bmp .ppm) which displayed correctly; and failure (.png .tif) as for the encoding: $ opj_decompress -i bell_206.j2k -o bell_206.bmp ... [INFO] Generated Outfile bell_206.bmp $ opj_decompress -i bell_206.j2k -o bell_206.ppm ... [INFO] Generated Outfile bell_206.ppm $ opj_decompress -i bell_206.j2k -o bell_206.png ... [ERROR] Outfile bell_206.png not generated $ opj_decompress -i bell_206.j2k -o bell_206.tif ... [ERROR] Outfile bell_206.tif not generated This behaviour was the same BEFORE the update (I reverted & checked it): openjpeg2-2.1.2-1.1.mga5 lib64openjp2_7-2.1.2-1.1.mga5 so I am OKing this update (no reversion) despite the dubious behaviour of the packages. Perhaps this is just on my system. Next tester please cross-check.
CC: (none) => lewyssmithWhiteboard: (none) => MGA5-64-OK
Whiteboard: MGA5-64-OK => MGA5-64-OK advisory
@Lewis re comment 3. Will do. And when I have time a 32-bit vbox test. A whole lot of CVEs again and the report offers to supply a PoC if contacted by email. Don't know if that is worth following up.
CC: (none) => tarazed25
http://manpages.ubuntu.com/manpages/yakkety/man1/opj_compress.1.html Extract: Valid input image extensions are .bmp, .pgm, .pgx, .png, .pnm, .ppm, .raw, .tga, .tif . For PNG resp. TIF it needs libpng resp. libtiff . This machine has lib64png16_16 and lib64tiff5. $ opj_compress -i indian_blackbuck.png -o blackbuck.j2k Unable to load file: got no image $ opj_compress -i lena_color.tiff -o lenacolor.j2k [ERROR] Unknown input file format: lena_color.tiff Known file formats are *.pnm, *.pgm, *.ppm, *.pgx, *png, *.bmp, *.tif, *.raw or *.tga So, "dubious behaviour" is confirmed with respect to PNG and TIFF formats. opj_decompress works fine for PPM and PNM output formats but not PNG or TIFF. Updated packages worked fine apart from the unsupported "supported" formats. opj_dump of a J2K file shows the structure of the data in the file.
i586 virtualbox Updated the packages and checked that libpng and libtiff were installed. Used the three utilities to convert between PNM, PPM, JP2 and J2K file formats. The resulting images displayed fine. Used opj_dump to show the data structure of a JP2 file. As before compressing PNG and TIFF files failed. The overall behaviour of the 32bit packages is no different from 64bits so this can be passed.
Whiteboard: MGA5-64-OK advisory => MGA5-64-OK advisory MGA5-32-OK
Keywords: (none) => validated_updateWhiteboard: MGA5-64-OK advisory MGA5-32-OK => MGA5-64-OK advisory MGA5-32-OKCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGASA-2017-0051.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED