Hi,
I'm recently fuzzing with AFL (http://lcamtuf.coredump.cx/afl/) and got a few crashes.
I posted it a few days ago on oss-security mailing list. Hope this didn't cause you any trouble.
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);
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) {
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
Publicizing something like this in a public forum without first contacting the author/maintainer and giving them time (a week or two should be sufficient) is highly irresponsible and highly un-professional.
I'm really sorry. This is my first time doing this. I just follow the instructions on oss-security wiki
http://oss-security.openwall.org/wiki/disclosure/researcher. And I thought publishing on the bugtrack or posting on the mailing list were the same, until someone reminded me that I should contact the maintainer first.
Really sorry for that.
Last edit: Erik 2015-02-17
Err... Is there anything i can do to help fix the bug?
No, not really. I've got a fix for the two SEGVs, still working on the other one. The biggest problem is that I won't get a chance to do a release unil the weekend.
Fixed in this git commit: