In Bug 30291, we fixed a CVE with a buggy patch from Debian. A fixed version of the patch has been posted here: https://www.openwall.com/lists/oss-security/2023/03/14/7
Whiteboard: (none) => MGA8TOO
Done for both mga8 and Cauldron!
Advisory: ---------------------------------------- The sox package has been updated with a corrected patch for CVE-2021-33844 which fixes a regression that made sox unable to decode WAV GSM files. References: https://www.openwall.com/lists/oss-security/2023/03/14/7 https://advisories.mageia.org/MGASA-2023-0059.html ---------------------------------------- Updated packages in core/updates_testing: ---------------------------------------- sox-14.4.3-0.git20200117.3.2.mga8 libsox3-14.4.3-0.git20200117.3.2.mga8 libsox-devel-14.4.3-0.git20200117.3.2.mga8 from sox-14.4.3-0.git20200117.3.2.mga8.src.rpm
CC: (none) => geiger.david68210Whiteboard: MGA8TOO => (none)Version: Cauldron => 8Assignee: geiger.david68210 => qa-bugs
mageia8, x86_64 The question here for testers is how do we identify WAV GSM files? The first two tried were Signed and Unsigned PCM - seems to be the order of the day. A bit of research reveals that GSM is a lossy conversion from a higher sampling rate to 8000 Hz, more useful for speech. $ play Semiramis.wav File Size: 82.4M Bit Rate: 1.41M Encoding: Signed PCM Channels: 2 @ 16-bit Samplerate: 44100Hz $ sox Semiramis.wav semiramis.gsm sox WARN formats: gsm can't encode at 44100Hz; using 8000Hz $ play semiramis.gsm File Size: 1.54M Encoding: GSM Channels: 1 @ 16-bit Samplerate: 8000Hz The GSM file played OK but the original sound was extremely degraded. Updated the packages and ran that test again. $ play BadMoonRising.wav File Size: 12.2M Bit Rate: 706k Encoding: Signed PCM Channels: 1 @ 32-bit Samplerate: 22050Hz $ sox BadMoonRising.wav badmoonrising.gsm sox WARN formats: gsm can't encode at 22050Hz; using 8000Hz sox WARN rate: rate clipped 1 samples; decrease volume? sox WARN dither: dither clipped 1 samples; decrease volume? $ play badmoonrising.gsm File Size: 229k Encoding: GSM Channels: 1 @ 16-bit Samplerate: 8000Hz The sound was slightly degraded maybe, hardly noticeable. Tried the original file and found the conversion badly degraded, as before. Other conversions play well with sox. $ sox OrganConcerto_7.4_D_minor.wav handel.flac $ play handel.flac File Size: 68.9M Bit Rate: 672k Encoding: FLAC Info: Processed by SoX Channels: 2 @ 16-bit Samplerate: 44100Hz $ play MilleDucas.mp3 File Size: 1.42M Bit Rate: 128k Encoding: MPEG audio Channels: 2 @ 16-bit Samplerate: 44100Hz $ sox PourQuoy.mp3 pourquoy.ogg $ play pourquoy.ogg File Size: 1.62M Bit Rate: 106k Encoding: Vorbis Info: Processed by SoX Channels: 2 @ 16-bit Samplerate: 44100Hz All good.
CC: (none) => tarazed25Whiteboard: (none) => MGA8-64-OK
Addendum to comment 3. The man page for sox gives numerous examples of use for combining tracks, recording and sysnthesizing sounds on the fly, such as: $ play -n -c1 synth sin %-12 sin %-9 sin %-5 sin %-2 fade h 0.1 1 0.1 That works too.
Validating. Advisory in comment 2.
CC: (none) => andrewsfarm, sysadmin-bugsKeywords: (none) => validated_update
Keywords: (none) => advisoryCC: (none) => davidwhodgins
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2023-0027.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
Ubuntu has issued an advisory for this on March 20: https://ubuntu.com/security/notices/USN-5904-2
Blocks: (none) => 31753