Fedora has issued an advisory on January 31: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/QJTWGZLBNOSKCUFIH7AQANEJPFF7DVDL/ The issue is fixed upstream in 2.5.
Status comment: (none) => Fixed upstream in 2.5
The only listed changes since ver. 2.4 was this bug fix, so I took the liberty of updating directly to ver. 2.5. advancecomp-2.5-1.mga9 is now available in updates_testing. I don't have access to a MNG file showing the issue, so here is a simple regression test that merely ensures the common PNG use case still works (the patched did touch the PNG code): $ cp /usr/lib/libDrakX/icons/tradi.png /tmp && advpng -z /tmp/tradi.png && advpng -l /tmp/tradi.png && echo ok This will display "ok" on the last line, with no error messages showing, if all is well. The upstream log for this says "Fix segmentation fault on invalid MNG size". I couldn't find a CVE entry for this. Advisory: ======================== advancecomp has been updated to fix a crash with a malformed MNG file. Updated packages: ======================== advancecomp-2.5-1.mga8.i586.rpm advancecomp-2.5-1.mga8.x86_64.rpm advancecomp-2.5-1.mga8.aarch64.rpm
Status: NEW => ASSIGNEDKeywords: (none) => has_procedureAssignee: dan => qa-bugs
mga8, x64 $ rpm -q advancecomp advancecomp-2.4-1.mga8 $ cp /usr/lib/libDrakX/icons/tradi.png /tmp && advpng -z /tmp/tradi.png && advpng -l /tmp/tradi.png && echo ok 33212 20696 62% /tmp/tradi.png 33212 20696 62% IHDR 13 width:264 height:198 depth:8 color_type:2 compression:0 filter:0 interlace:0 IDAT 20639 IEND 0 ok Waiting for the mirror to sync.
CC: (none) => tarazed25
Meanwhile: $ advmng -z iwarp-anim.mng && advmng -l iwarp-anim.mng 19642 19642 100% iwarp-anim.mng (Unsupported size change) 19642 19642 100% MHDR 28 width:100 height:100 frequency:1000 simplicity:511(bit,0,1,2,3,4,5,6,7,8) TERM 10 tEXt 28 tIME 7 FRAM 27 mode:3 len:0 delay_mode:2 timeout:0 clip:2 syncid:0 tick:100 timeout:0 dt:0 ... IHDR 13 width:100 height:100 depth:8 color_type:2 compression:0 filter:0 interlace:0 IDAT 1275 IEND 0 FRAM 27 mode:3 len:0 delay_mode:2 timeout:0 clip:2 syncid:0 tick:100 timeout:0 dt:0 ... IHDR 13 width:100 height:100 depth:8 color_type:6 compression:0 filter:0 interlace:0 IDAT 1408 IEND 0 FRAM 27 mode:3 len:0 delay_mode:2 timeout:0 clip:2 syncid:0 tick:100 timeout:0 dt:0 ... IHDR 13 width:100 height:100 depth:8 color_type:6 compression:0 filter:0 interlace:0 IDAT 2758 IEND 0 FRAM 27 mode:3 len:0 delay_mode:2 timeout:0 clip:2 syncid:0 tick:100 timeout:0 dt:0 ... IHDR 13 width:100 height:100 depth:8 color_type:6 compression:0 filter:0 interlace:0 IDAT 3066 IEND 0 FRAM 27 mode:3 len:0 delay_mode:2 timeout:0 clip:2 syncid:0 tick:100 timeout:0 dt:0 ... IHDR 13 width:100 height:100 depth:8 color_type:6 compression:0 filter:0 interlace:0 IDAT 3283 IEND 0 FRAM 27 mode:3 len:0 delay_mode:2 timeout:0 clip:2 syncid:0 tick:100 timeout:0 dt:0 ... IHDR 13 width:100 height:100 depth:8 color_type:6 compression:0 filter:0 interlace:0 IDAT 3403 IEND 0 FRAM 27 mode:3 len:0 delay_mode:2 timeout:0 clip:2 syncid:0 tick:100 timeout:0 dt:0 ... IHDR 13 width:100 height:100 depth:8 color_type:6 compression:0 filter:0 interlace:0 IDAT 3692 IEND 0 MEND 0
CC: (none) => danStatus comment: Fixed upstream in 2.5 => (none)
Continuing with the same image; it displays as an animation of the word GIMP using mplayer. It loops until it is killed. Updated via qarepo. Tried the GIMP animation: $ mplayer iwarp-anim.mng MPlayer 1.4-9.3.mga8.tainted-10 (C) 2000-2019 MPlayer Team <remote control stuff> Playing iwarp-anim.mng. libavformat version 58.45.100 (external) Mismatching header version 58.27.102 libavformat file format detected. [image2 @ 0x7f7859dbc780]Could find no file with path 'mp:iwarp-anim.mng' and index in the range 0-4 LAVF_header: av_open_input_stream() failed MNG file format detected. VIDEO: [ BGR] 100x100 32bpp 5.000 fps 0.0 kbps ( 0.0 kbyte/s) .... $ advpng -l Comet67P.png IHDR 13 width:1024 height:768 depth:8 color_type:6 compression:0 filter:0 interlace:0 bKGD 6 pHYs 9 tIME 7 IDAT 8192 IDAT 8192 .... Compress file in place. $ ll Comet67P.png -rw-r--r-- 1 lcl lcl 517917 Aug 7 2014 Comet67P.png $ advpng -z --shrink-extra Comet67P.png 517917 490158 94% Comet67P.png 517917 490158 94% $ ll Comet67P.png -rw-r--r-- 1 lcl lcl 490158 Feb 2 00:08 Comet67P.png So far so good. Shall try to compress an mng file in the morning.
Tried to convert a stream of images into an MNG video using ffmpeg - failed. Tried advmng: $ advmng --add 24 newfile.mng Alaina*.png Invalid bit depth change [at void mng_write_image_raw(adv_mng_write*, adv_fz*, unsigned int*, unsigned int, unsigned int, unsigned int, unsigned char*, unsigned int, unsigned char*, unsigned int, int, int):mngex.cc:586] So back to the only MNG in the known universe: iwarp-anim.mng. Actually there are sources online but a browser needs a plugin to display the images. Made a copy -> anim.mng $ advmng -l anim.mng MHDR 28 width:100 height:100 frequency:1000 simplicity:511(bit,0,1,2,3,4,5,6,7,8) TERM 10 tEXt 28 tIME 7 [...] $ ll anim.mng -rw-r--r-- 1 lcl lcl 19642 Feb 2 00:34 anim.mng Tried various compression options like --shrink-fast and --shrink-normal which reported 'Unsupported size change'. -shrink-store said the same thing. $ advmng -z --shrink-store anim.mng 19642 19642 100% anim.mng (Unsupported size change) 19642 19642 100% Leaving this up in the air. The png utility seems to work but the mng application fails on compression unless I am mis-reading the documentation.
Oops - forgot Dan's regression test. $ cp /usr/lib/libDrakX/icons/tradi.png /tmp && advpng -z /tmp/tradi.png && advpng -l /tmp/tradi.png && echo ok cp: overwrite '/tmp/tradi.png'? y 33212 20696 62% /tmp/tradi.png 33212 20696 62% IHDR 13 width:264 height:198 depth:8 color_type:2 compression:0 filter:0 interlace:0 IDAT 20639 IEND 0 ok Confirms the PNG side of things.
I think that size change message just means that the file is already optimized and can't be made any smaller. I found an MNG file at https://filesamples.com/samples/image/mng/sample_1920%C3%971280.mng that advdef -z works on, but none of the video players I have installed will properly play either the original or the recompressed version of that file. But, I get some kind of image out of both versions so I guess it's working.
Same here. The star-trail image(s) display(s) for a short period with ImageMagick then closes. Yes, you are probably correct about the unsupported size change. That had crossed my mind. Considering your tests lets give this the OK.
Whiteboard: (none) => MGA8-64-OK
Thank you for your efforts, Gentlemen. Validating. Advisory in comment 1.
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-2023-0041.html
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVED