A CVE was assigned for a security issue reported for audiofile: http://openwall.com/lists/oss-security/2015/10/08/1 There's a pull request with a suggested patch linked in the message above, but upstream commented that the included test case fails, so we'll have to wait for an accepted patch. Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA5TOO
The additional comments indicate that a number in the test case needs to be changed depending on which version of audiofile it's used with. Otherwise, it sounds like the patch should be fine. Our package doesn't run the test suite, and fails with linking errors when you try, so probably our best way to test this will be the test case program attached to the Ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/audiofile/+bug/1502721
Patched packages uploaded for Mageia 5 and Cauldron. Advisory: ======================== Updated audiofile packages fix security vulnerability: When libaudiofile is used to change both the number of channels of an audio file (e.g. from stereo to mono) and the sample format (e.g. from 16-bit samples to 8-bit samples), the output file will contain corrupted data. If the new sample format is smaller than the old one, there is a risk of buffer overflow: e.g. when the input file has 16-bit samples and the output file has 8-bit samples, afReadFrames will treat the buffer to read the samples (argument void *data) as a pointer to int16_t instead of int8_t, therefore it will write past its end (CVE-2015-7747). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7747 http://openwall.com/lists/oss-security/2015/10/08/1 ======================== Updated packages in core/updates_testing: ======================== audiofile-0.3.6-4.1.mga5 libaudiofile1-0.3.6-4.1.mga5 libaudiofile-devel-0.3.6-4.1.mga5 from audiofile-0.3.6-4.1.mga5.src.rpm
Version: Cauldron => 5Assignee: bugsquad => qa-bugsWhiteboard: MGA5TOO => (none)
Whiteboard: (none) => advisoryCC: (none) => davidwhodgins
The test program as per Comment 1 is - AFAICS - a crafted version of an existing piece of the audiofile package to force the overflow to appear. With that I cannot prove that the problem would not occur anymore in the updated package as this should prevent the problem, thus exactly the opposite. Proving implies that one would go and chase some audio file that triggers the problem in the old version, as the bug says " there is a RISK of buffer overflow" It is a pity such audio file is not provided. And after a few tries to compile the test program, I come under the impression it cannot be compiled standalone, one would need to compile and link a complete test package and that's over the top for me right now in the time I can spent on it.
CC: (none) => herman.viaene
My impression was that the test program actually creates the bad audio file programmatically. Getting it to compile does appear to be an issue.
I got it to compile (just had to include the header from the test directory in the source), but similar to upstream's complaint, it prints an error: error expected 1, got -101 if I change the 792 to 392 (which appears to be the right thing to do), still an error: error expected 0, got -101 So this test case isn't usable. Just test an app that uses the library, like kwave, mpd, or normalize.
Testing M5 x64 real hardware. Following suggestions from Comment 5, I installed just lib64audiofile1, and added the applications kwave, mpd, normalize. I never got mpd to work, so gave up on it. Normalize does not say as much, but seems to require MP3 input. Kwave accepted both FLAC & MP3. It is somewhat flaky. If you don't have either format, but something different (*.wma in my case), ffmpeg is your friend - once you understand it:- $ ffmpeg -i "01 Track 1.wma" track1.flac $ ffmpeg -i "01 Track 2.wma" -codec mp3 track2.mp3 BEFORE update, lib64audiofile1-0.3.6-4.mga5: Played minimally with Kwave. It showed the FLAC files as their proper time, but the MP3 ones at twice their length - the 2nd half empty. Whether this is down to ffmpeg conversion, or Kwave itself, I know not. $ normalize track1.mp3 track2.mp3 Computing levels... track2.mp3 100% done, ETA 00:00:00 (batch 100% done, ETA 00:00:00) Applying adjustment of -1.40dB to track1.mp3... track1.mp3 100% done, ETA 00:00:00 (batch 50% done, ETA 00:00:00) Applying adjustment of -2.58dB to track2.mp3... track2.mp3 100% done, ETA 00:00:00 (batch 100% done, ETA 00:00:00) Re-created the two MP3 files to be pre-normalized. AFTER update: audiofile-0.3.6-4.1.mga5 [added manually, not used by these tests] lib64audiofile1-0.3.6-4.1.mga5 Same behaviour as previously with Kwave. $ normalize track1.mp3 track2.mp3 gave identical results to previously. Update OK as no obvious regression.
CC: (none) => lewyssmithWhiteboard: advisory => advisory MGA5-64-OK
MGA5-32 on AcerD620 Xfce. No installation issues. Followed more or less Comment 6: Copied 2 .wav tracks from a CD used ffmpeg to convert to mp3 and made copies of both. Loaded lib64audiofile1-0.3.6-4.mga5 and at CLI: $ normalize track1.mp3 track2.mp3 Computing levels... track2.mp3 100% done, ETA 00:00:00 (batch 100% done, ETA 00:00:00) Applying adjustment of 1,69dB to track1.mp3... track1.mp3 100% done, ETA 00:00:00 (batch 46% done, ETA 00:00:00) Applying adjustment of 2,54dB to track2.mp3... track2.mp3 100% done, ETA 00:00:00 (batch 100% done, ETA 00:00:00) I have no idea why it runs track2 twice, but is same as above. Loaded then lib64audiofile1-0.3.6-4.1.mga5 and after restoring the mp3 files from their copies: $ normalize track1.mp3 track2.mp3 Computing levels... track2.mp3 100% done, ETA 00:00:00 (batch 100% done, ETA 00:00:00) Applying adjustment of 1,69dB to track1.mp3... track1.mp3 100% done, ETA 00:00:00 (batch 46% done, ETA 00:00:01) Applying adjustment of 2,54dB to track2.mp3... track2.mp3 100% done, ETA 00:00:00 (batch 100% done, ETA 00:00:00) OK for me.
Whiteboard: advisory MGA5-64-OK => advisory MGA5-64-OK MGA5-32-OK
Validating this update
Keywords: (none) => validated_updateCC: (none) => wilcal.int, sysadmin-bugs
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGASA-2015-0408.html
Status: NEW => RESOLVEDResolution: (none) => FIXED
URL: (none) => http://lwn.net/Vulnerabilities/662063/