search for: read_subframe_lpc_

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) << 32) ) > */ > if(bps + subframe->...

...bc based system. If this isn't good enough (and it isn't for SSE2), > we will have to replace appropriate malloc calls. It isn't, and I'm currently doing just that. > However, you can copy qlp_coeffs on stack for better alignment. You mean copying them into a local array in read_subframe_lpc_(), right? I'd still have to manually align that array, though, or am I missing something? > IIRC powerpc has performance counters, if you want the best code, use them. Good idea. Cpocuba, or however that would approximate in Roman letters :) . -- Brady Patterson (brady@spaceship.com) Do...

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

.../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_verbatim_(FLAC__StreamDecoder *decoder, unsigned channel, unsigned bps, FLAC__bool do_full_decode); -static FLAC__bool read_residual_partitioned_rice_(FLA...

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:

...AC__MAX_EXTRA_RESIDUAL_BPS bits wider than subframe_bps, I think it should be: if(subframe_bps + qlp_coeff_precision + FLAC__bitmath_ilog2(order) + FLAC__MAX_EXTRA_RESIDUAL_BPS - 1 <= 32) if(subframe_bps + FLAC__MAX_EXTRA_RESIDUAL_BPS <= 16 && qlp_coeff_precision <= 16) > vs. read_subframe_lpc_(): > > if(bps + subframe->qlp_coeff_precision + FLAC__bitmath_ilog2(order) <= 32) > if(bps <= 16 && subframe->qlp_coeff_precision <= 16) > decoder->private_->local_lpc_restore_signal_16bit(...); > else > decoder->private_->local_lpc_restor...

...fer 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 is smaller than the predic...

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 partition order is 0 and blocks...

...oder->private_->frame.header.blocksize < order) + return true; + /* decode the subframe */ if(do_full_decode) { memcpy(decoder->private_->output[channel], subframe->warmup, sizeof(FLAC__int32) * order); @@ -2688,6 +2691,9 @@ FLAC__bool read_subframe_lpc_(FLAC__StreamDecoder *decoder, unsigned channel, un FLAC__ASSERT(0); } + if (decoder->private_->frame.header.blocksize < order) + return true; + /* decode the subframe */ if(do_full_decode) { memcpy(decode...

...eturns > 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 decoder considers the se...

In the precompute_partition_info_sums_ function, instead of selecting 64-bit accumulator when the signal bps is larger than 16, revert to the original approach based on partition size, but make room for few extra bits to not overflow with unusual signals where the average residual magnitude may be larger than bps. It slightly improves the performance with standard encoding levels and 16-bit files

...CH_FOR_FRAME_SYNC; + return true; + } subframe->entropy_coding_method.data.partitioned_rice.order = u32; subframe->entropy_coding_method.data.partitioned_rice.contents = &decoder->private_->partitioned_rice_contents[channel]; break; @@ -2673,6 +2675,11 @@ FLAC__bool read_subframe_lpc_(FLAC__StreamDecoder *decoder, unsigned channel, un 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 fo...

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

Howdy. I'm working on Altivec versions of some of the libFLAC functions. I figured the best candidates would be those that had MMX/SSE/3dnow versions, and I picked FLAC__lpc_restore_signal() to do first, since it's relatively simple. In stepping through some runs, it appears that 'order' mod 4 is always 0. Is that guaranteed, either by the format or by higher functions in the