similar to: Two new CVEs against FLAC

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

On 25.11.2014 12:14, Miroslav Lichvar wrote: > 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, 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 > @@

On Tue, Nov 25, 2014 at 12:29:33AM -0800, Erik de Castro Lopo wrote: > 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 > https://git.xiph.org/?p=flac.git;a=commit;h=fcf0ba06ae12ccd7c67cee3c8d948df15f946b85 I'm trying to figure out how this one

On 9.12.2014 20:33, Tristan Matthews wrote: > On Tue, Dec 9, 2014 at 1:31 PM, Janne Hyv?rinen <cse at sci.fi > <mailto:cse at sci.fi>> wrote: > > On 25.11.2014 12:14, Miroslav Lichvar wrote: > > 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 >

On 9.12.2014 20:31, Janne Hyv?rinen wrote: > On 25.11.2014 12:14, Miroslav Lichvar wrote: >> 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, the function would return true and blocksize-order in >> the caller would still underflow. >> >> ---

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)

To avoid crash caused by an unbound LPC decoding when predictor order is larger than blocksize, the sanity check needs to be moved to the subframe decoding functions. --- src/libFLAC/stream_decoder.c | 30 ++++++++++++------------------ 1 file changed, 12 insertions(+), 18 deletions(-) diff --git a/src/libFLAC/stream_decoder.c b/src/libFLAC/stream_decoder.c index d13b23b..211b4db 100644 ---

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

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

On Thu, Jun 19, 2014 at 03:30:06PM +0200, Miroslav Lichvar wrote: > But, as we have seen with unusual data the residual signal can be > wider than bps. The FLAC format specification doesn't seem to mention > this. Should it be treated as a valid FLAC stream? I think it would be interesting to know how common are such streams. I patched flac to print a warning on decoding or testing

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

2014-12-11 14:34 GMT+01:00 Miroslav Lichvar <mlichvar at redhat.com>: > > 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

> -----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

MSVS profiler shows that the following code in stream_encoder.c takes several percent of CPU time: for(rice_parameter = 0, k = partition_samples; k < mean; rice_parameter++, k <<= 1) ; this code is equivalent to: rice_parameter = 0; k = partition_samples; while(k < mean) { rice_parameter++; k <<= 1; } The idea was to accelerate it:

Or, I was originally thinking: rice_parameter = 0; k = partition_samples; if (k < mean) { int n = mean - k; rice_parameter += n; k <<= n; } (sorry for the hasty post) On Oct 11, 2013, at 10:34, Brian Willoughby wrote: > Hmm, maybe I'm missing something, but what about this: > > rice_parameter = 0; k = partition_samples; > int n = mean - k; > if (n >

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

A user of CRAM (http://swami.sourceforge.net/cram.php) sent in a bug report related to decoding of CRAM files. This issue occurs with flac-1.1.2 but not previous versions (such as flac-1.1.1). Note that the same file is used for this test (hopefully ruling out any issue with the encoder). Details of the issue: When calling FLAC__stream_decoder_process_single() the error callback is triggered

Hi Rui, We meet a problem when enable the execute in place (XIP, https://en.wikipedia.org/wiki/Execute_in_place) for uefi firmware with lld-link. We need to set the COFF executable file SectionAlignment through the lld-link /ALIGN option, but we find the SectionAlignment is hardcoded to 4096 which cause the /ALIGN option doesn't work at all. Below is the hardcode in lld: lld\COFF\Writer.h

> -----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

Hi, The FLAC__stream_decoder_flush doesn't change the state, but when I play a stream and reach the end I have to do a FLAC__stream_decoder_reset and reread the metadata instead of simply a FLAC__stream_decoder_flush. This is because the stream state, which indicates the end of the stream, is not changed. Is there a reason, for the state not being reset to