my libprintf module identified a format string vulnerability in mpg321's parsing of id3 comments. This could be exploited with a malicious mp3 files to execute arbitrary code. Mar 20 18:43:19 insomniac mpg321: [24030] no format specifiers: fprintf(/dev/pts/10, "The Hives Are Law, You Are Cri"); Mar 20 18:43:19 insomniac mpg321: [24030] no format specifiers: fprintf(/dev/pts/10, "The Hives "); Mar 20 18:43:19 insomniac mpg321: [24030] no format specifiers: fprintf(/dev/pts/10, "Your New Favourite Band "); Mar 20 18:43:19 insomniac mpg321: [24030] no format specifiers: fprintf(/dev/pts/10, "2001"); Mar 20 18:43:19 insomniac mpg321: [24030] no format specifiers: fprintf(/dev/pts/10, "Created by Grip "); Mar 20 18:43:19 insomniac mpg321: [24030] no format specifiers: fprintf(/dev/pts/10, "Other "); I checked the package and noticed mpg321-0.2.10-r2, currently only ~ppc-macos, fixes this issue with a patch from freebsd, this fix needs to be marked stable for everyone else to fix this issue. An example that would crash mpg321 (in case anyone wants to verify): $ id3tag -wnc__FOOB test.mp3 $ perl -pi -e 's/__FOOB/%.500n/g' test.mp3 $ mpg321 test.mp3 (id3tag wont set % characters in comment).
media-sound/mpg123 is also affected by this issue.
oops, no it isnt..disregard that.
CVE-2003-0969
The only difference between mpg321-0.2.10-r1 (currently KEYWORDS="amd64 x86 ~ppc sparc mips alpha ppc64") and mpg321-0.2.10-r2 (currently KEYWORDS="-* ~ppc-macos") is the addition of a patch from freebsd which is "obviously correct", it fixes this security issue and looks like it fixes a couple of fd leaks. -r2 should be ready for arch stabilisation.
Arches, for mpg321-0.2.10-r2: amd64 x86 sparc mips alpha ppc64: please test and mark stable ppc: please test and mark ~ppc Ccing sound team, in case it wants to test and mark stable a few arches by itself
Stable on sparc.
stable on amd64 and x86
Stable on ppc.
Stable on alpha.
stable on ppc64
GLSA 200503-34
Stable on mips.