Op 11-12-14 om 10:05 schreef Miroslav Lichvar: > but I'd rather see the real seeking bug fixed instead
I think I might have a fix, but it touches quite a bit of code, so it'll take some time. I think the problem is that because bogus headers might pop up in the stream of which the CRC checks out, the whole frame is decoded to validate that a frame is correct. The bogus header might trigger the sanity checks that were made to fail by the CVEs, thereby the seek fails. A fix for this might be not decoding a frame fully, (by making the /*do_full_decode=*/true in FLAC__stream_decoder_process_single conditionally dependent on decoder->private_->is_seeking) but instead implement more sanity checks. For example, it could be checked whether the sample rate, blocksize, number of channels and sample size in the frame header match with those in the stream info, and whether the sample or framenumber is in a sane range. This gives less security than fully decoding the frame, but it ensures the seek process will no longer fail because of these CVE sanity checks. I'm not sure whether this will work, especially when there's no STREAMINFO block. This could be handled by fully decoding the first frame that is encountered to set these values from the frame header, but that would mean the seeking code becomes even more unreadable. _______________________________________________ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
