desktop-packages team mailing list archive
-
desktop-packages team
-
Mailing list archive
-
Message #145956
[Bug 1502721] Re: When changing both sample format and number of channels, data gets corrupted; if new sample format smaller than old, possible buffer overflow
This bug was fixed in the package audiofile - 0.3.6-2ubuntu0.14.04.1
---------------
audiofile (0.3.6-2ubuntu0.14.04.1) trusty-security; urgency=medium
* SECURITY UPDATE: buffer overflow when changing both sample format and
number of channels (LP: #1502721)
- debian/patches/CVE-2015-7747.patch: don't corrupt files in
libaudiofile/modules/ModuleState.cpp, added test to test/Makefile.am,
test/sixteen-stereo-to-eight-mono.c.
- CVE-2015-7747
-- Marc Deslauriers <marc.deslauriers@xxxxxxxxxx> Tue, 20 Oct 2015
07:57:26 -0400
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to audiofile in Ubuntu.
https://bugs.launchpad.net/bugs/1502721
Title:
When changing both sample format and number of channels, data gets
corrupted; if new sample format smaller than old, possible buffer
overflow
Status in audiofile package in Ubuntu:
Fix Released
Bug description:
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.
The attached program (which is a rework of a file already present in
the upstream's test suite, reworked by me) shows the problem. The 2
variables byte and abyte are int8_t. afReadFrames is told to read 1
8-bit sample into byte, but ends up treating &byte as a pointer to an
int16_t, thus overwriting abyte (when abyte is stored right after byte
in memory, which is what happens when I compile with gcc).
I proposed a fix (before realising about the buffer overflow, only
about the data corruption) at
https://github.com/mpruett/audiofile/pull/25
ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: libaudiofile1 0.3.6-2
ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3
Uname: Linux 3.19.0-15-generic x86_64
ApportVersion: 2.17.2-0ubuntu1.5
Architecture: amd64
CurrentDesktop: Unity
Date: Sun Oct 4 23:55:03 2015
InstallationDate: Installed on 2010-11-07 (1792 days ago)
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)
SourcePackage: audiofile
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/audiofile/+bug/1502721/+subscriptions