search for: read_residual_partitioned_rice_

...tatic 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_(FLAC__StreamDecoder *decoder, unsigned predictor_order, unsigned partition_order, FLAC__EntropyCodingMethod_PartitionedRiceContents *partitioned_rice_contents, FLAC__int32 *residual, FLAC__bool is_extended); +static FLAC__bool read_residual_partitioned_rice_(FLAC__StreamDecoder *decoder, unsigned p...

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:

...ow 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 predictor order. > > Is that correct? Yes. > I think the case with non-zero partition order may need to be fixed > too. For example, with partition order of 1, predic...

> -----Ursprungliche Nachricht----- > Von: Josh Coalson > > yes, I will probably get to it soon after the release. > the encoding side is pretty convoluted but for decoding, > src/libFLAC/stream_decoder.c:read_residual_partitioned_rice_() > should be pretty straightforward once you ignore the > FLAC__SYMMETRIC_RICE stuff (which is not used). feel free to > ask questions about it here. Yes, I did find that part after tracing through the code, and I already have a few questions. - I am right, that the FLAC__bitbuffer_rea...

...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 predictor order. Is that correct? I think the case with non-zero partition order may need to be fixed too. For example, with partition order of 1, predictor order of 16 and blocksize of 4, t...

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

> -----Ursprungliche Nachricht----- > Von: Josh Coalson > > --- Tor-Einar Jarnbjo <Tor-Einar_Jarnbjo@grosch-link.de> wrote: > > Hi, > > > > have I just overseen a link, or is the format description on > > http://flac.sourceforge.net/format.html lacking information on how to > > actually decode the residual partitions to PCM sample data? > > you

I think I've gotten FLAC__lpc_restore_signal() about as good as I'm going to get it. Here's what I have: -a new file, lpc_asm.s, which has the assembly routines -changes to cpu.h, cpu.c, and stream_decoder.c to enable them -changes to configure.in to support the new cpu stuff -a preliminary Makefile.am -maybe something else I'm forgetting Now automake complains that configure.in

...SUBFRAME_TYPE_FIXED; ! subframe->residual = residual; subframe->order = order; /* read warm-up samples */ *************** *** 1841,1847 **** /* read residual */ switch(subframe->entropy_coding_method.type) { case FLAC__ENTROPY_CODING_METHOD_PARTITIONED_RICE: ! if(!read_residual_partitioned_rice_(decoder, order, subframe->entropy_coding_method.data.partitioned_rice.order, &decoder->private_->partitioned_rice_contents[channel], decoder->private_->residual[channel])) return false; break; default: --- 1854,1860 ---- /* read residual */ switch(subframe-&g...

...example, with partition order of 1, predictor order of 16 and > blocksize of 4, the function would return true and blocksize-order in > the caller would still underflow. > > --- a/src/libFLAC/stream_decoder.c > +++ b/src/libFLAC/stream_decoder.c > @@ -2744,7 +2744,7 @@ FLAC__bool read_residual_partitioned_rice_(FLAC__StreamDecoder *decoder, unsigne > if(partition_samples < predictor_order) { > send_error_to_client_(decoder, FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC); > decoder->protected_->state = FLAC__STREAM_DECODER_S...

Hi all, I am interested in building a stand alone Rice Encoder/Decoder, using FLAC source code as a starting point. I've read the theory behind it, and I am very interested in info theory. However, I am struggling with how exactly I would implement the theory in code. I'm a newbie to computer science (only 1 year experience). I have read the format and documentation links on the FLAC

...> near > future? I took a quick look at the libFLAC sources, but the OO-like > implementation and pointer-shuffling is not very easy to understand. yes, I will probably get to it soon after the release. the encoding side is pretty convoluted but for decoding, src/libFLAC/stream_decoder.c:read_residual_partitioned_rice_() should be pretty straightforward once you ignore the FLAC__SYMMETRIC_RICE stuff (which is not used). feel free to ask questions about it here. > The reason I am asking is, that I've started to implement a FLAC > decoder for > the Java Media Framework cool, that was on my TODO list...

...someone who just learned > what ./configure meant today. Well, configure is obfuscating, but that's not really the problem. You're on the right track; the rice encode/decode stuff is all in libFLAC/stream_decoder.c, stream_encoder.c, and stream_encoder_framing.c. The decoder routine read_residual_partitioned_rice_() might be a good place to start. FLAC is highly modular code with lots of interfaces and abstraction layers; it takes lots of tracing to follow the flow and sort out the actual implementation. Keep at it though; it's good practice. > P.S. I totally appreciate the very clean code and docu...

...> blocksize of 4, the function would return true and > blocksize-order in > > the caller would still underflow. > > > > --- a/src/libFLAC/stream_decoder.c > > +++ b/src/libFLAC/stream_decoder.c > > @@ -2744,7 +2744,7 @@ FLAC__bool > read_residual_partitioned_rice_(FLAC__StreamDecoder *decoder, unsigne > > if(partition_samples < predictor_order) { > > send_error_to_client_(decoder, > FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC); > > decoder->protected_->state = > FLAC__STREAM_DECODER_SEARCH...

...order of 1, predictor order of 16 and >> blocksize of 4, the function would return true and blocksize-order in >> the caller would still underflow. >> >> --- a/src/libFLAC/stream_decoder.c >> +++ b/src/libFLAC/stream_decoder.c >> @@ -2744,7 +2744,7 @@ FLAC__bool read_residual_partitioned_rice_(FLAC__StreamDecoder *decoder, unsigne >> if(partition_samples < predictor_order) { >> send_error_to_client_(decoder, FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC); >> decoder->protected_->state = FLAC__S...

...ds 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 seeking proces failed. This is only a problem...

...ing arg 2 of `FLAC__bitreader_read_unary_unsigned' from incompatible pointer type bitreader.c: In function `FLAC__bitreader_read_rice_signed_block': bitreader.c:850: warning: passing arg 2 of `FLAC__bitreader_read_raw_uint32' from incompatible pointer type stream_decoder.c: In function `read_residual_partitioned_rice_': stream_decoder.c:2774: warning: passing arg 2 of `FLAC__bitreader_read_rice_signed_block' from incompatible pointer type stream_decoder.c:2783: warning: passing arg 2 of `FLAC__bitreader_read_raw_int32' from incompatible pointer type Apart from that, this also leads to format string...

...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; @@ -2744,21 +2751,8 @@ FLAC__bool read_residual_partitioned_rice_(FLAC__StreamDecoder *decoder, unsigne const unsigned plen = is_extended? FLAC__ENTROPY_CODING_METHOD_PARTITIONED_RICE2_PARAMETER_LEN : FLAC__ENTROPY_CODING_METHOD_PARTITIONED_RICE_PARAMETER_LEN; const unsigned pesc = is_extended? FLAC__ENTROPY_CODING_METHOD_PARTITIONED_RICE2_ESCAPE_PARAMETER :...

...what ./configure meant today. > > Well, configure is obfuscating, but that's not really the problem. > > You're on the right track; the rice encode/decode stuff is all > in libFLAC/stream_decoder.c, stream_encoder.c, and > stream_encoder_framing.c. The decoder routine > read_residual_partitioned_rice_() might be a good place to start. > > FLAC is highly modular code with lots of interfaces and abstraction > layers; it takes lots of tracing to follow the flow and sort out > the actual implementation. Keep at it though; it's good practice. > > > P.S. I totally appreciate...