search for: read_subframe_fixed_

On Thu, Dec 11, 2014 at 11:12:25AM +0100, Martijn van Beurden wrote: > Op 11-12-14 om 10:53 schreef Martijn van Beurden: > > 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 [...] So the problem is that FLAC__stream_decoder_process_single returns error before it finds a

...-------- diff --git a/src/libFLAC/stream_decoder.c b/src/libFLAC/stream_decoder.c index ddd8979..82318ae 100644 --- a/src/libFLAC/stream_decoder.c +++ b/src/libFLAC/stream_decoder.c @@ -99,7 +99,7 @@ static FLAC__bool read_subframe_constant_(FLAC__StreamDecoder *decoder, unsigned static FLAC__bool read_subframe_fixed_(FLAC__StreamDecoder *decoder, unsigned channel, unsigned bps, const unsigned order, FLAC__bool do_full_decode); static FLAC__bool read_subframe_lpc_(FLAC__StreamDecoder *decoder, unsigned channel, unsigned bps, const unsigned order, FLAC__bool do_full_decode); static FLAC__bool read_subframe_verb...

On Thu, Jun 19, 2014 at 03:30:22PM +0400, lvqcl wrote: > BTW, what can you say about the following place in stream_decoder.c > in read_subframe_lpc_() function: > > /*@@@@@@ technically not pessimistic enough, should be more like > if( (FLAC__uint64)order * ((((FLAC__uint64)1)<<bps)-1) * ((1<<subframe->qlp_coeff_precision)-1) < (((FLAC__uint64)-1)

Hi all, Google Security Team member, Michele Spagnuolo, recently found two potential problems in the FLAC code base. They are : CVE-2014-9028 : Heap buffer write overflow CVE-2014-8962 : Heap buffer read overflow For Linux distributions, the specific fixes for these two CVEs are available from Git here:

...CVE-2014-9028 : Heap buffer write overflow > https://git.xiph.org/?p=flac.git;a=commit;h=fcf0ba06ae12ccd7c67cee3c8d948df15f946b85 I'm trying to figure out how this one works. It seems the problem is integer underflow in the "frame.header.blocksize-order" expression used in read_subframe_fixed_() and read_subframe_lpc_() to get the number of encoded samples, which causes a buffer overflow in the LPC/fixed subframe decoding. The fix prevents that by returning false from read_residual_partitioned_rice_() to stop further decoding of the subframe when the partition order is 0 and blocksize i...

Miroslav Lichvar wrote: > I'm trying to figure out how this one works. It seems the problem is > integer underflow in the "frame.header.blocksize-order" expression > used in read_subframe_fixed_() and read_subframe_lpc_() to get the > number of encoded samples, which causes a buffer overflow in the > LPC/fixed subframe decoding. > > The fix prevents that by returning false from > read_residual_partitioned_rice_() to stop further decoding of > the subframe when the partit...

...e code below should catch that, but I'd rather see the real seeking bug fixed instead and not hide it like this. Returning success with invalid/uninitialized data seems like a bad idea to me. --- a/src/libFLAC/stream_decoder.c +++ b/src/libFLAC/stream_decoder.c @@ -2609,6 +2609,9 @@ FLAC__bool read_subframe_fixed_(FLAC__StreamDecoder *decoder, unsigned channel, FLAC__ASSERT(0); } + if (decoder->private_->frame.header.blocksize < order) + return true; + /* decode the subframe */ if(do_full_decode) { memcpy(decoder-&...

...decoder_process_single returns > error before it finds a valid frame? > I'm not sure whether we mean the same thing, but I think the problem is that seek_to_absolute_sample_ calls FLAC__stream_decoder_process_single, which calls read_frame_, which calls read_subframe_, which calls either read_subframe_fixed_ or read_subframe_lpc_, which call read_residual_partitioned_rice_. The return false set there is propagated all the way down. So, because the decoding of the frame is aborted upon finding a situation in which a heap overflow might be in order (but which will usually just be a bogus header), the de...

...mum value. Plumb through predictor_order maybe? */ - size = size < FLAC__MAX_LPC_ORDER ? FLAC__MAX_LPC_ORDER : size ; - if(size <= decoder->private_->output_capacity && channels <= decoder->private_->output_channels) return true; @@ -2594,6 +2591,11 @@ FLAC__bool read_subframe_fixed_(FLAC__StreamDecoder *decoder, unsigned channel, case FLAC__ENTROPY_CODING_METHOD_PARTITIONED_RICE2: if(!FLAC__bitreader_read_raw_uint32(decoder->private_->input, &u32, FLAC__ENTROPY_CODING_METHOD_PARTITIONED_RICE_ORDER_LEN)) return false; /* read_callback_ sets the state for u...

...dual_partitioned_rice_ (decoder=0x805ba58, predictor_order=3, partition_order=14, partitioned_rice_contents=0x805f478, residual=0x807dd80) at stream_decoder.c:1975 rice_parameter = 9 i = 2 partition = 0 sample = 0 u = 4294967293 partitions = 16384 partition_samples = 0 #2 0x4021f01f in read_subframe_fixed_ (decoder=0x805ba58, channel=1, bps=16, order=3) at stream_decoder.c:1832 subframe = (FLAC__Subframe_Fixed *) 0x805f988 i32 = -31667 u32 = 14 u = 14 #3 0x4021ecd7 in read_subframe_ (decoder=0x805ba58, channel=1, bps=1) at stream_decoder.c:1751 x = 22 wasted_bits = 0 #4 0x4021e190 in read_fra...

Erik de Castro Lopo wrote: > I think I have an alternative fix for the CVE which should not break > seeking. I'm working on getting an copy of the file with which to test. Patch applied and pushed. commit b4b2910bdca010808ccf2799f55562fa91f4347b Author: Erik de Castro Lopo <erikd at mega-nerd.com> Date: Wed Dec 10 18:54:16 2014 +1100