From ${URL} : Several bugs found in the latest libflac and libtta codec fuzzing with AFL ( http://lcamtuf.coredump.cx/afl/), working together with Nie Sen, from K33nTeam. The input POC files can be found on https://sourceforge.net/projects/pocfiles/files/ --------------------------------------------------------------------------------------------------------------------------------------- Libflac 1.3.1 SEGV in libFLAC.so Run : ./flac -e -f -o ~/out.ogg t1.flac Codes related : src/libFLAC/stream_encoder.c line:2143 Function FLAC__stream_encoder_process() for(channel = 0; channel < channels; channel++) memcpy(&encoder->private_->integer_signal[channel][encoder->private_->current_sample_number], &buffer[channel][j], sizeof(buffer[channel][0]) * n); Reference: http://xiph.org/flac/ --------------------------------------------------------------------------------------------------------------------------------------- Libflac 1.3.1 Codec Frontend Bug Run : ./flac -e -f -o ~/out.ogg t2.flac Code Related : src/flac/encoder.c line:1878 Function EncoderSession_init_encoder() else if(e->total_samples_to_encode != cs->tracks[cs->num_tracks-1].offset) { Reference: http://xiph.org/flac/ --------------------------------------------------------------------------------------------------------------------------------------- Libflac 1.3.1 Stack overflow In Command-line flac encoder/decoder tool, bytes_to_read is not properly checked against the size of ucbuffer, which causes a stack overflow when performing fread in encoding. Codes related to the crash are in src/flac/encode.c function flac__encode_file() const size_t bytes_to_read = (size_t)min( encoder_session.fmt.iff.data_bytes, (FLAC__uint64)CHUNK_OF_SAMPLES * (FLAC__uint64)encoder_session.info.bytes_per_wide_sample ); bytes_read = fread(ucbuffer.u8, sizeof(unsigned char), bytes_to_read, infile); POC: ./flac -e -f -o ~/test.flac ~/libflac_stack.wav Reference: http://xiph.org/flac/ @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
and from http://www.openwall.com/lists/oss-security/2015/02/14/4 : I think I haven't posted this here yet: Also recently fuzzed flac with afl and found something: https://git.xiph.org/?p=flac.git;a=commit;h=43ba7ad05f1656e885ce2f34a9a72494f45705ae https://sourceforge.net/p/flac/bugs/421/ Crashing sample is attached to the bug report. What happens is that flac does an malloc for the number of comments. If that fails due to an insane number of comments it'll fail, but it will still try to access the non-allocated memory. I think the upstream fix is not optimal - it limits the amount of allowed comments. That probably fixes this in most situations, but it still leaves problems, because it doesn't check for malloc failures.
Fixes are not yet released; I ping'ed upstream (https://github.com/xiph/flac/issues/19) to request a new release.
@ Maintainer(s): v1.3.2 which contains the fix was released today.
In tree via https://gitweb.gentoo.org/repo/gentoo.git/commit/media-libs/flac?id=32d9af62ee97eb977b752b5f507a6cda897de5a2 @ Maintainer(s): Can we stabilize: =media-libs/flac-1.3.2
I've done some minor touchups - please proceed with stabilization.
@ Arches, please test and mark stable: =media-libs/flac-1.3.2
amd64 stable
arm stable
An automated check of this bug failed - the following atom is unknown: media-libs/flac-1.3.2-r1 Please verify the atom list.
ppc stable
Stable on alpha.
x86 stable
ia64 stable
sparc stable
ppc64 stable
Stable for HPPA.
No ACE/RCE, downgraded to B3. GLSA Vote: No @ Maintainer(s): Please cleanup and drop =media-libs/flac-1.3.1-r1!
Arches and Maintainer(s), Thank you for your work.
Tree is clean.
