A stack-based buffer overflow vulnerability was discovered [1] in the way that that libmodplug handled S3M media files. If an attacker were able to coerce a user into opening a malicious S3M media file with an application linked to libmodplug, it could be possible to execute arbitrary code with the privileges of the user running the application. This has been corrected upstream [2] in 0.8.8.2 [1] https://www.sec-consult.com/files/20110407-0_libmodplug_stackoverflow.txt [2] http://modplug-xmms.git.sourceforge.net/git/gitweb.cgi?p=modplug-xmms/modplug-xmms;a=commitdiff;h=aecef259828a89bb00c2e6f78e89de7363b2237b
Created libmodplug tracking bugs for this issue Affects: fedora-all [bug 695421] Affects: epel-all [bug 695422]
This also affects gstreamer-plugins on Red Hat Enterprise Linux 4 and schismtracker in Fedora (they have embedded modplug).
Created schismtracker tracking bugs for this issue Affects: fedora-all [bug 695455]
This was assigned the name CVE-2011-1574.
(In reply to comment #2) > This also affects gstreamer-plugins on Red Hat Enterprise Linux 4 and > schismtracker in Fedora (they have embedded modplug). schismtracker in F-15+ doesn't seem to contain the embedded libmodplug any longer. I haven't tried to check if their new implementation would be affected by the same issue though.
I've poked around and it doesn't look like schismtracker in F15 has any similar issues (at least not that I can spot). It does look like it can handle s3m files still, but doesn't use modplug and hasn't really copied the code that I can see (at least not the affected code). So this would just be relevant for F13 and F14 from what I can see.
The EPEL-5 and EPEL-6 updates have sat in testing for 14 days, without any feedback. I don't have a system to test them with myself; perhaps someone receiving these mails could help?
This issue has been addressed in following products: Red Hat Enterprise Linux 4 Via RHSA-2011:0477 https://rhn.redhat.com/errata/RHSA-2011-0477.html