Debian-LTS has issued an advisory on July 11: https://www.debian.org/lts/security/2020/dla-2277 Mageia 7 is also affected.
Whiteboard: (none) => MGA7TOO
Done for both Cauldron and mga7!
CC: (none) => geiger.david68210
Advisory: ======================== Updated openjpeg2 packages fix security vulnerability: jp2/opj_decompress.c in OpenJPEG through 2.3.1 has a use-after-free that can be triggered if there is a mix of valid and invalid files in a directory operated on by the decompressor. Triggering a double-free may also be possible. This is related to calling opj_image_destroy twice (CVE-2020-15389). References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15389 https://www.debian.org/lts/security/2020/dla-2277 ======================== Updated packages in core/updates_testing: ======================== openjpeg2-2.3.1-1.4.mga7 libopenjp2_7-2.3.1-1.4.mga7 libopenjpeg2-devel-2.3.1-1.4.mga7 from openjpeg2-2.3.1-1.4.mga7.src.rpm
Assignee: bugsquad => qa-bugsVersion: Cauldron => 7Whiteboard: MGA7TOO => (none)
mga7, x86_64 CVE-2020-15389 https://github.com/uclouvain/openjpeg/issues/1261 $ opj_decompress -ImgDir inputs -OutFor pgm $ opj_decompress -ImgDir inputs -OutFor pgm Folder opened successfully File Number 0 "balloon.jpm" =========================================== The extension of this file is incorrect. FOUND .jpm. SHOULD BE .jp2 =========================================== [ERROR] JP2H box missing. Required. ERROR -> opj_decompress: failed to read the header These files are meant to produce output within the asan framework and upstream end in ABORT. Updated the three packages. $ opj_decompress -ImgDir inputs -OutFor pgm Folder opened successfully File Number 0 "balloon.jpm" =========================================== The extension of this file is incorrect. FOUND .jpm. SHOULD BE .jp2 =========================================== [ERROR] JP2H box missing. Required. ERROR -> opj_decompress: failed to read the header So, no change there but the test has a tidy exit and the pgm directory is empty. Note that the invalid file is intended to be treated as such because the fault would have triggered on a mixture of good and bad files as stated in the advisory. Probable good result. $ opj_compress -i ikapati.ppm -o ikapati.jp2 [INFO] tile number 1 / 1 [INFO] Generated outfile ikapati.jp2 encode time: 222 ms $ gm display ikapati.jp2 <image displays as expected> opj_dump -i ikapati.jp2 [INFO] Start to read j2k main header (85). [INFO] Main header has been correctly decoded. Image info { x0=0, y0=0 x1=1434, y1=717 numcomps=3 component 0 { <and so on....> $ opj_decompress -i ikapati.jp2 -o ikapati.bmp [INFO] Start to read j2k main header (85). [INFO] Main header has been correctly decoded. [INFO] No decoded area parameters, set the decoded area to the whole image [INFO] Header of tile 1 / 1 has been read. [INFO] Stream reached its end ! [INFO] Generated Outfile ikapati.bmp decode time: 108 ms $ gm display ikapati.bmp <Looks as good as new> Avoided PNG, although it is supposed to be supported, because PNG images can come in one of several compression modes. None here are suitable. This looks good to go.
Whiteboard: (none) => MGA7-64-OKCC: (none) => tarazed25
That was a quick one. Validating. Advisory in Comment 2.
Keywords: (none) => validated_updateCC: (none) => andrewsfarm, sysadmin-bugs
CC: (none) => davidwhodginsKeywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2020-0307.html
Status: NEW => RESOLVEDResolution: (none) => FIXED