Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
Secunia wrote: Secunia Research has discovered a vulnerability in libsndfile, which can be exploited by malicious people to compromise an application using the library. The vulnerability is caused due to an integer overflow error in the processing of CAF description chunks. This can be exploited to cause a heap-based buffer overflow by tricking the user into processing a specially crafted CAF audio file. Successful exploitation may allow execution of arbitrary code. The vulnerability is confirmed in version 1.0.18. Prior versions may also be affected. SOLUTION: Update to version 1.0.19. PROVIDED AND/OR DISCOVERED BY: Alin Rad Pop, Secunia Research ORIGINAL ADVISORY: Secunia Research: http://secunia.com/secunia_research/2009-7/ libsndfile: http://www.mega-nerd.com/libsndfile/ChangeLog
Created an attachment (id=183894) [details] Patch to libsndfile-1.0.18-r1.ebuild to create libsndfile-1.0.19.ebuild Rename of 1.0.18-r1 ebuild almost works, but the m4 macro patch has been applied upstream and so has to be removed from the ebuild. Attached patch makes the necessary change, which then builds correctly on x86.
(In reply to comment #1) > Created an attachment (id=183894) [edit] [details] > Patch to libsndfile-1.0.18-r1.ebuild to create libsndfile-1.0.19.ebuild > > Rename of 1.0.18-r1 ebuild almost works, but the m4 macro patch has been > applied upstream and so has to be removed from the ebuild. Attached patch makes > the necessary change, which then builds correctly on x86. bumped, thanks
Arches, please test and mark stable: =media-libs/libsndfile-1.0.19 Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 sh sparc x86"
fails testsuite here on amd64/x86, older versions had it disabled: ========================== ./lossy_comp_test aiff_ima ========================== test_float_peak : peak_float.aiff ......... ok read_write_peak_test : rw_peak.aiff ............ ok update_header_test : header.aiff ............. ok update_seek_short_test : header_short.aiff ....... ok update_seek_int_test : header_int.aiff ......... ok update_seek_float_test : header_float.aiff ....... ok update_seek_double_test : header_double.aiff ...... ok header_shrink_test : header_shrink.wav ....... ok extra_header_test : extra.aiff .............. ok zero_data_test : zerolen.aiff ............ ok filesystem_full_test : /dev/full ............... Line 300 : Error bad error string : System error : Permission denied.. make[1]: *** [check] Error 1 make[1]: Leaving directory `/var/tmp/portage/media-libs/libsndfile-1.0.19/work/libsndfile-1.0.19/tests' make: *** [check-recursive] Error 1 * * ERROR: media-libs/libsndfile-1.0.19 failed. * Call stack: * ebuild.sh, line 49: Called src_test * environment, line 2708: Called _eapi0_src_test * ebuild.sh, line 616: Called die * The specific snippet of code: * hasq test $FEATURES && die "Make check failed. See above for details." * The die message: * Make check failed. See above for details.
(In reply to comment #4) > zero_data_test : zerolen.aiff ............ ok > filesystem_full_test : /dev/full ............... > weird, I had exactly this failure with the .18 pre releases but when I bumped it to the .18 it wasn't failing anymore; can you try to see if upgrading your sandbox helps? I'll probably disable this test for now but I'd like to know why :)
ppc64 done
On alpha, I get this: >>> Emerging (1 of 1) sci-chemistry/gromacs-4.0.3 * gromacs-4.0.3.tar.gz RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * You need one of these Fortran Compilers: g77 gfortran ifc * Installed are: gfortran >>> Unpacking source... >>> Unpacking gromacs-4.0.3.tar.gz to /var/tmp/portage/sci-chemistry/gromacs-4.0.3/work * Running eautoreconf in '/var/tmp/portage/sci-chemistry/gromacs-4.0.3/work/gromacs-4.0.3' ... * Running aclocal ... [ ok ] * Running true --copy --force --install --automake ... [ ok ] * Running aclocal ... [ ok ] * Running autoconf ... [ ok ] * Running autoheader ... [ ok ] * Running automake --add-missing --copy --foreign ... [ ok ] * Running elibtoolize in: gromacs-4.0.3/config * Applying install-sh-1.5.4.patch ... * Applying portage-1.5.10.patch ... * Applying sed-1.5.6.patch ... >>> Source unpacked in /var/tmp/portage/sci-chemistry/gromacs-4.0.3/work >>> Compiling source in /var/tmp/portage/sci-chemistry/gromacs-4.0.3/work ... * * ERROR: sci-chemistry/gromacs-4.0.3 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 3075: Called die * The specific snippet of code: * die "If you must run gromacs without sse (not recommended) gfortran will not work."; * The die message: * If you must run gromacs without sse (not recommended) gfortran will not work. * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/log/portage/sci-chemistry:gromacs-4.0.3:20090312-223608.log'. * The ebuild environment file is located at '/var/tmp/portage/sci-chemistry/gromacs-4.0.3/temp/environment'. * >>> Failed to emerge sci-chemistry/gromacs-4.0.3, Log file: >>> '/var/log/portage/sci-chemistry:gromacs-4.0.3:20090312-223608.log' Naturally, I *can't* use SSE. So where do I get g77? ifc is right out for obvious reasons.
Gah. Wrong browser tab. Nevermind me.
Stable for HPPA.
(In reply to comment #5) > (In reply to comment #4) > > zero_data_test : zerolen.aiff ............ ok > > filesystem_full_test : /dev/full ............... > > > > weird, I had exactly this failure with the .18 pre releases but when I bumped > it to the .18 it wasn't failing anymore; can you try to see if upgrading your > sandbox helps? I'll probably disable this test for now but I'd like to know why > :) tests pass with sys-apps/sandbox-1.6
Stable on alpha.
ppc done
arm/ia64/sh/sparc stable, since tests failures aren't a blocker and previous versions had it restricted...
I'd like to move this bug to [glsa], however amd64 and x86 are still on ~arch. Either we need to RESTRICT=test or send a beer over to Markus, so he'll be happy.
x86 stable, now its amd64 issue :P
amd64 stable, all arches done.
GLSA request filed.
GLSA 200904-16
